Testing uninstall and reinstall of Epinio

Test to check what happens to applications deployed in different namespaces after uninstalling and reinstalling of Epinio.
Do they work? Will the workspace namespace be affected?
Steps:

Install epinio
Create svc, app, svc + bound
Create svc, app, svc + bound (in another ns)
Uninstall epinio with helm (in default ns)
Check pv`s after uninstall
Upgrade version

Expectation check if content in created ns survives

Tested as follows in Epinio Server Version: v1.10.0 with Kubernetes Version: v1.25.4+k3s1
(To reproduce change paths to correct local ones for pushing sample-app and wordpress app)
Push app in namespace workspace (default), create config and bind it:
epinio push -n sampleapp-workspace -p /home/mmartin/suse/epinio-repos/epinio/assets/sample-app
epinio configuration create config-workspace foo bar
sleep 2 # To avoid binding issues
epinio configuration bind config-workspace sampleapp-workspace

Create and target namespace ns-1, push app, create config and bind it
epinio namespace create ns-1
epinio target ns-1
epinio push -n sampleapp-1 -p /home/mmartin/suse/epinio-repos/epinio/assets/sample-app
epinio configuration create config-1 foo bar
sleep 2 # To avoid binding issues
epinio configuration bind config-1 sampleapp-1

Create and target namespace wordpress, push app, create service and bind it
epinio namespace create ns-wordpress
epinio target ns-wordpress
epinio service create mysql-dev mycustom-service
epinio push --name testapp-wordpress --path /home/mmartin/suse/epinio-repos/example-wordpress -e BP_PHP_VERSION=8.0.x -e BP_PHP_SERVER=nginx -e BP_PHP_WEB_DIR=wordpress -e DB_HOST=x8e5ee833a0f2faebaf5c4171baca-mysql -e SERVICE_NAME=mycustom-service
sleep 2 # To avoid binding issues
epinio service bind mycustom-service testapp-wordpress

Check namespaces with apps binded and pv status
kubectl get pv -n epinio
epinio namespace list

Output:
➜  epinio git:(main) kubectl get pv -n epinio
epinio namespace list
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                                    STORAGECLASS   REASON   AGE
pvc-e0395823-6606-4992-97e9-53ad271a7464   2Gi        RWO            Delete           Bound    epinio/image-export-pvc                                                  local-path              9m32s
pvc-3e85e426-bab7-4edf-8303-3bbb2aade7c6   2Gi        RWO            Delete           Bound    epinio/export-2-minio-0                                                  local-path              9m30s
pvc-6dd388dd-bfb0-45af-8210-80c0c28addcf   2Gi        RWO            Delete           Bound    epinio/export-0-minio-0                                                  local-path              9m30s
pvc-1a744f8b-4b5f-486f-a42a-3897f6f1bfe5   2Gi        RWO            Delete           Bound    epinio/export-1-minio-0                                                  local-path              9m29s
pvc-9c595532-3ef1-4bf1-a4c6-cc1fa1d7aac0   2Gi        RWO            Delete           Bound    epinio/export-3-minio-0                                                  local-path              9m26s
pvc-a3f12a55-cb2d-43ab-961c-573cc605b3dd   1Gi        RWO            Delete           Bound    epinio/workspace-sampleapp-wo-04fb72281b56bf4dc7939a380a9e4dffb401ff7e   local-path              7m59s
pvc-6a189e62-29a8-4938-91c3-313c4f975267   1Gi        RWO            Delete           Bound    epinio/ns-1-sampleapp-1-75a15fd088c58d057076198e7acdbf2b654e26ec         local-path              5m18s
pvc-b649676d-2c5f-4bf1-a3ec-e97b52ee1e28   8Gi        RWO            Delete           Bound    ns-wordpress/data-x8e5ee833a0f2faebaf5c4171baca-mysql-0                  local-path              94s
pvc-b3ce7d24-62bc-4935-aa18-4949ae1f856e   1Gi        RWO            Delete           Bound    epinio/ns-wordpress-testapp-w-bba6abcbf8c7409ec25c6c7db677ff685dcafc09   local-path              86s

🚢  Listing namespaces

✔  Epinio Namespaces:
|     NAME     |            CREATED             |    APPLICATIONS     |           CONFIGURATIONS            |
|--------------|--------------------------------|---------------------|-------------------------------------|
| ns-1         | 2023-09-27 13:24:29 +0200 CEST | sampleapp-1         | config-1                            |
| ns-wordpress | 2023-09-27 13:28:21 +0200 CEST | testapp-wordpress   | x8e5ee833a0f2faebaf5c4171baca-mysql |
| workspace    | 2023-09-27 13:20:23 +0200 CEST | sampleapp-workspace | config-workspace                    |

Uninstall epinio
helm uninstall epinio -n epinio

Re-install
helm upgrade --install epinio -n epinio --create-namespace epinio/epinio --set global.domain=<IP_ADDRESS>.omg.howdoi.website

Check namespaces with apps binded and pv status again
kubectl get pv -n epinio
epinio namespace list

Output:
➜  epinio git:(main) kubectl get pv -n epinio
epinio namespace list
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                                    STORAGECLASS   REASON   AGE
pvc-3e85e426-bab7-4edf-8303-3bbb2aade7c6   2Gi        RWO            Delete           Bound    epinio/export-2-minio-0                                                  local-path              11m
pvc-6dd388dd-bfb0-45af-8210-80c0c28addcf   2Gi        RWO            Delete           Bound    epinio/export-0-minio-0                                                  local-path              11m
pvc-1a744f8b-4b5f-486f-a42a-3897f6f1bfe5   2Gi        RWO            Delete           Bound    epinio/export-1-minio-0                                                  local-path              11m
pvc-9c595532-3ef1-4bf1-a4c6-cc1fa1d7aac0   2Gi        RWO            Delete           Bound    epinio/export-3-minio-0                                                  local-path              11m
pvc-a3f12a55-cb2d-43ab-961c-573cc605b3dd   1Gi        RWO            Delete           Bound    epinio/workspace-sampleapp-wo-04fb72281b56bf4dc7939a380a9e4dffb401ff7e   local-path              10m
pvc-6a189e62-29a8-4938-91c3-313c4f975267   1Gi        RWO            Delete           Bound    epinio/ns-1-sampleapp-1-75a15fd088c58d057076198e7acdbf2b654e26ec         local-path              7m21s
pvc-b649676d-2c5f-4bf1-a3ec-e97b52ee1e28   8Gi        RWO            Delete           Bound    ns-wordpress/data-x8e5ee833a0f2faebaf5c4171baca-mysql-0                  local-path              3m37s
pvc-b3ce7d24-62bc-4935-aa18-4949ae1f856e   1Gi        RWO            Delete           Bound    epinio/ns-wordpress-testapp-w-bba6abcbf8c7409ec25c6c7db677ff685dcafc09   local-path              3m29s
pvc-98b10187-7539-4877-aa80-6bd1adce5cc3   2Gi        RWO            Delete           Bound    epinio/image-export-pvc                                                  local-path              37s

🚢  Listing namespaces

✔  Epinio Namespaces:
|     NAME     |            CREATED             |   APPLICATIONS    |           CONFIGURATIONS            |
|--------------|--------------------------------|-------------------|-------------------------------------|
| ns-1         | 2023-09-27 13:24:29 +0200 CEST | sampleapp-1       | config-1                            |
| ns-wordpress | 2023-09-27 13:28:21 +0200 CEST | testapp-wordpress | x8e5ee833a0f2faebaf5c4171baca-mysql |
| workspace    | 2023-09-27 13:31:17 +0200 CEST |                   |                                     |

So content in namespaces ns-1 and ns-wordpress survive whereas workspace is gone.

I am actually unsure if the fact that content in the default namespace is not surviving in the above test is actually a bug or not.

After today's meeting, we agreed / clarified:

The above-described behavior seems to be the expected/accepted one.
We should document this to let the user know
We should test if the same occurs when deploying in Rancher. I will take care of that.

Tested in Rancher 2.7.7 with latest epinio 1.10.0 chart (from https://github.com/epinio/helm-charts pointing to main branch) and has similar behavior, default namespace does not survive whereas other namespaces do:

Before:

➜  epinio git:(main) kubectl get pv -n epinio
epinio namespace list
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                                    STORAGECLASS   REASON   AGE
pvc-6a71c505-d87e-4e59-86c5-8e871ac45a16   2Gi        RWO            Delete           Bound    epinio/image-export-pvc                                                  local-path              9m1s
pvc-a5ef48e2-163e-40a3-bf93-ca81d40ec19b   2Gi        RWO            Delete           Bound    epinio/export-1-minio-0                                                  local-path              8m59s
pvc-b5c124d7-8f52-477d-8aae-200a6c83490f   2Gi        RWO            Delete           Bound    epinio/export-0-minio-0                                                  local-path              8m59s
pvc-6bf327e9-09dc-42a6-8efd-c167832012c7   2Gi        RWO            Delete           Bound    epinio/export-3-minio-0                                                  local-path              8m57s
pvc-190250b4-105b-4ff1-92a2-04b2bb25a948   2Gi        RWO            Delete           Bound    epinio/export-2-minio-0                                                  local-path              8m56s
pvc-21c4a425-6aa7-4400-aebd-2d872d263e44   1Gi        RWO            Delete           Bound    epinio/workspace-sampleapp-wo-04fb72281b56bf4dc7939a380a9e4dffb401ff7e   local-path              3m9s
pvc-7a971218-7871-4bb0-af1f-c2b59000f12d   1Gi        RWO            Delete           Bound    epinio/ns-1-sampleapp-1-75a15fd088c58d057076198e7acdbf2b654e26ec         local-path              101s
pvc-64f79810-3eee-4947-8fa1-fc7de5d17551   8Gi        RWO            Delete           Bound    ns-wordpress/data-x8e5ee833a0f2faebaf5c4171baca-mysql-0                  local-path              55s
pvc-97acf435-deae-4a48-a652-b42dff358906   1Gi        RWO            Delete           Bound    epinio/ns-wordpress-testapp-w-bba6abcbf8c7409ec25c6c7db677ff685dcafc09   local-path              42s

🚢  Listing namespaces

✔  Epinio Namespaces:
|     NAME     |            CREATED             |    APPLICATIONS     |           CONFIGURATIONS            |
|--------------|--------------------------------|---------------------|-------------------------------------|
| ns-1         | 2023-10-02 10:40:00 +0200 CEST | sampleapp-1         | config-1                            |
| ns-wordpress | 2023-10-02 10:40:56 +0200 CEST | testapp-wordpress   | x8e5ee833a0f2faebaf5c4171baca-mysql |

After:

➜  epinio git:(main) kubectl get pv -n epinio
epinio namespace list
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                                    STORAGECLASS   REASON   AGE
pvc-a5ef48e2-163e-40a3-bf93-ca81d40ec19b   2Gi        RWO            Delete           Bound    epinio/export-1-minio-0                                                  local-path              16m
pvc-b5c124d7-8f52-477d-8aae-200a6c83490f   2Gi        RWO            Delete           Bound    epinio/export-0-minio-0                                                  local-path              16m
pvc-6bf327e9-09dc-42a6-8efd-c167832012c7   2Gi        RWO            Delete           Bound    epinio/export-3-minio-0                                                  local-path              16m
pvc-190250b4-105b-4ff1-92a2-04b2bb25a948   2Gi        RWO            Delete           Bound    epinio/export-2-minio-0                                                  local-path              16m
pvc-21c4a425-6aa7-4400-aebd-2d872d263e44   1Gi        RWO            Delete           Bound    epinio/workspace-sampleapp-wo-04fb72281b56bf4dc7939a380a9e4dffb401ff7e   local-path              10m
pvc-7a971218-7871-4bb0-af1f-c2b59000f12d   1Gi        RWO            Delete           Bound    epinio/ns-1-sampleapp-1-75a15fd088c58d057076198e7acdbf2b654e26ec         local-path              8m48s
pvc-64f79810-3eee-4947-8fa1-fc7de5d17551   8Gi        RWO            Delete           Bound    ns-wordpress/data-x8e5ee833a0f2faebaf5c4171baca-mysql-0                  local-path              8m2s
pvc-97acf435-deae-4a48-a652-b42dff358906   1Gi        RWO            Delete           Bound    epinio/ns-wordpress-testapp-w-bba6abcbf8c7409ec25c6c7db677ff685dcafc09   local-path              7m49s
pvc-713a9726-b09f-41ac-bb9b-45202bf2bbb7   2Gi        RWO            Delete           Bound    epinio/image-export-pvc                                                  local-path              68s

🚢  Listing namespaces

✔  Epinio Namespaces:
|     NAME     |            CREATED             |   APPLICATIONS    |           CONFIGURATIONS            |
|--------------|--------------------------------|-------------------|-------------------------------------|
| ns-1         | 2023-10-02 10:40:00 +0200 CEST | sampleapp-1       | config-1                            |
| ns-wordpress | 2023-10-02 10:40:56 +0200 CEST | testapp-wordpress | x8e5ee833a0f2faebaf5c4171baca-mysql |
| workspace    | 2023-10-02 10:47:48 +0200 CEST |                   |                                     |

@mmartin24 thanks, but what I mean is to test with the E Rancher App which doesn't create the workspace ns when installing. Anyway lets test it within v1.10.0 E Rancher App validation.

Rechecked with default chart where namespace namespace workspace is not present.
What was observed is that content in that namespace is persistent after epinio deletion and re-install.
This seems reasonable in Rancher.
However, it looks like the existing application in Rancher is not to be recognized by Epinio after re-install.
Here we see how app rsample , bound to a service exists:
epinio namespace show workspace

🚢  Showing namespace...
Name: workspace

⚠  Epinio server version (v1.9.0) doesn't match the client version (v1.10.0)

⚠  Update the client manually or run `epinio client-sync`

✔  Details:
|      KEY       |                VALUE                |
|----------------|-------------------------------------|
| Name           | workspace                           |
| Created        | 2023-10-03 13:24:30 +0200 CEST      |
| Applications   |                                     |
| Configurations | xc11fadea2478b7bb684678d6d8a8-mysql |
thehejik@dhcp236:~> k get all -n workspace
NAME                                                                  READY   STATUS    RESTARTS   AGE
pod/rsample-8151325dcdbae9e0ff95f9f9658432dbedfdb209-6b446c7f96svbm   1/1     Running   0          13m
pod/xc11fadea2478b7bb684678d6d8a8-mysql-0                             1/1     Running   0          13m

NAME                                                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/rsample-8151325dcdbae9e0ff95f9f9658432dbedfdb209   ClusterIP   <IP_ADDRESS>   <none>        8080/TCP   16m
service/xc11fadea2478b7bb684678d6d8a8-mysql-headless       ClusterIP   None            <none>        3306/TCP   13m
service/xc11fadea2478b7bb684678d6d8a8-mysql                ClusterIP   <IP_ADDRESS>   <none>        3306/TCP   13m

NAME                                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/rsample-8151325dcdbae9e0ff95f9f9658432dbedfdb209   1/1     1            1           16m

NAME                                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/rsample-8151325dcdbae9e0ff95f9f9658432dbedfdb209-6b446c7f97   1         1         1       13m
replicaset.apps/rsample-8151325dcdbae9e0ff95f9f9658432dbedfdb209-66c7d45bf    0         0         0       16m

NAME                                                   READY   AGE
statefulset.apps/xc11fadea2478b7bb684678d6d8a8-mysql   1/1     13m

but the app seems not listed by Epinio:
epinio app list

:ship:  Listing applications
Namespace: workspace

:warning:  Epinio server version (v1.9.0) doesn't match the client version (v1.10.0)

:warning:  Update the client manually or run `epinio client-sync`

:heavy_check_mark:  Epinio Applications:
| NAME | CREATED | STATUS | ROUTES | CONFIGURATIONS | STATUS DETAILS |
|------|---------|--------|--------|----------------|----------------|

Will open bug about it


Feature/fix timeslider styling

Correct an issue with RTSTimeSlider when customizing its color in a storyboard and add the possibility to show the total stream duration instead of the time left value.

The initial styling is sadly still brokenl:

The slider knob of the default media player view controller layout is large, but is expected to be small
The slider knob is missing in demos using custom layouts (e.g. demo for segments). Using the default initial color (nil) should probably set the color to white instead

Well, this PR is probably a bit outdated 😇. We can now also customize slider labels.


Vulnerability roundup 106: gpac-1.0.1: 33 advisories [8.8]

search, files

[ ] CVE-2021-21834 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21835 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21836 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21837 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21838 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21839 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21840 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21841 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21842 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21843 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21844 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21845 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21846 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21847 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21848 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21849 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21850 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21851 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21852 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21853 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21854 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21855 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21856 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21857 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21858 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21859 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21860 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21861 CVSSv3=8.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-21862 CVSSv3=7.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-32439 CVSSv3=7.8 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-32437 CVSSv3=5.5 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-32438 CVSSv3=5.5 (nixos-21.05, nixos-unstable)
[ ] CVE-2021-32440 CVSSv3=5.5 (nixos-21.05, nixos-unstable)

CVE details
CVE-2021-21834
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input when decoding the atom for the “co64” FOURCC can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21835
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input when decoding the atom associated with the “csgp” FOURCC can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21836
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input using the “ctts” FOURCC code can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21837
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21838
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21839
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21840
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input used to process an atom using the “saio” FOURCC code cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21841
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input when reading an atom using the 'sbgp' FOURCC code can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21842
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow when processing an atom using the 'ssix' FOURCC code, due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21843
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. After validating the number of ranges, at [41] the library will multiply the count by the size of the GF_SubsegmentRangeInfo structure. On a 32-bit platform, this multiplication can result in an integer overflow causing the space of the array being allocated to be less than expected. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21844
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input when encountering an atom using the “stco” FOURCC code, can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21845
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input in “stsc” decoder can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21846
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input in “stsz” decoder can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21847
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input in “stts” decoder can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21848
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. The library will actually reuse the parser for atoms with the “stsz” FOURCC code when parsing atoms that use the “stz2” FOURCC code and can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21849
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow when the library encounters an atom using the “tfra” FOURCC code due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21850
An exploitable integer overflow vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow when the library encounters an atom using the “trun” FOURCC code due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21851
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input at “csgp” decoder sample group description indices can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21852
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input at “stss” decoder can cause an integer overflow due to unchecked arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21853
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked addition arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21854
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked addition arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21855
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked addition arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21856
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked addition arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21857
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked addition arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21858
Multiple exploitable integer overflow vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an integer overflow due to unchecked addition arithmetic resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21859
An exploitable integer truncation vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. The stri_box_read function is used when processing atoms using the 'stri' FOURCC code. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21860
An exploitable integer truncation vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an improper memory allocation resulting in a heap-based buffer overflow that causes memory corruption. The FOURCC code, 'trik', is parsed by the function within the library. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21861
An exploitable integer truncation vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. When processing the 'hdlr' FOURCC code, a specially crafted MPEG-4 input can cause an improper memory allocation resulting in a heap-based buffer overflow that causes memory corruption. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-21862
Multiple exploitable integer truncation vulnerabilities exist within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an improper memory allocation resulting in a heap-based buffer overflow that causes memory corruption The implementation of the parser used for the “Xtra” FOURCC code is handled. An attacker can convince a user to open a video to trigger this vulnerability.
CVE-2021-32439
Buffer overflow in the stbl_AppendSize function in MP4Box in GPAC 1.0.1 allows attackers to cause a denial of service or execute arbitrary code via a crafted file.
CVE-2021-32437
The gf_hinter_finalize function in GPAC 1.0.1 allows attackers to cause a denial of service (NULL pointer dereference) via a crafted file in the MP4Box command.
CVE-2021-32438
The gf_media_export_filters function in GPAC 1.0.1 allows attackers to cause a denial of service (NULL pointer dereference) via a crafted file in the MP4Box command.
CVE-2021-32440
The Media_RewriteODFrame function in GPAC 1.0.1 allows attackers to cause a denial of service (NULL pointer dereference) via a crafted file in the MP4Box command.

Scanned versions: nixos-21.05: 6120ac5cd20; nixos-unstable: bc9b956714e.
Cc @bluescreen303
Cc @mgdelacroix

See also: #133957, #124632

We no longer support nixos-21.05, but this has been fixed in the currently supported NixOS versions:

nixos-22.05: gpac-2.0.0
nixos-unstable: gpac-2.0.0


Ubuntu 24 installation

Ubuntu has connect to internet without problems
martin@ubuntudock:/docker/csirt$ sudo apt-get install ca-certificates curl gnupg lsb-release
curl -fsSL https://azlux.fr/repo.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/azlux-archive-keyring.gpg
echo
"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/azlux-archive-keyring.gpg] http://packages.azlux.fr/debian
$(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/azlux.list >/dev/null
sudo apt-get update
sudo apt-get install docker-ctop
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ca-certificates is already the newest version (20240203).
curl is already the newest version (8.5.0-2ubuntu10.4).
gnupg is already the newest version (2.4.4-2ubuntu17).
lsb-release is already the newest version (12.0-2).
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
 Done
E: The repository 'http://packages.azlux.fr/debian noble Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package docker-ctop

I changed noble to bullseye and
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package ctop

I was able to install on 24.04 by adding
Enabled: yes
Types: deb
URIs: http://packages.azlux.fr/debian/
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/azlux-archive-keyring.gpg

to /etc/apt/sources.list.d/third-party.sources
and then doing sudo apt-get update && sudo apt-get install docker-ctop

aaaaleluja :) thank you jwjacobs88 it`s works now, thank you again

https://github.com/bcicen/ctop/issues/357#issuecomment-2395124593


No such file or directory: 'I830000_E32_gen.pth'

I tried upscaling a simple picture using the colab notebook but instead getting this "No such file.." error on running the last cell

21-11-13 09:59:49.904 - INFO: Dataset [LRHRDataset - CelebaHQ] is created.
21-11-13 09:59:49.904 - INFO: Initial Dataset Finished
21-11-13 10:00:06.355 - INFO: Loading pretrained model for G [I830000_E32] ...
Traceback (most recent call last):
File "infer.py", line 46, in
diffusion = Model.create_model(opt)
File "/content/Image-Super-Resolution-via-Iterative-Refinement/model/init.py", line 7, in create_model
m = M(opt)
File "/content/Image-Super-Resolution-via-Iterative-Refinement/model/model.py", line 42, in init
self.load_network()
File "/content/Image-Super-Resolution-via-Iterative-Refinement/model/model.py", line 158, in load_network
gen_path), strict=(not self.opt['model']['finetune_norm']))
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 594, in load
with _open_file_like(f, 'rb') as opened_file:
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 230, in _open_file_like
return _open_file(name_or_buffer, mode)
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 211, in init
super(_open_file, self).init(open(name, mode))
FileNotFoundError: [Errno 2] No such file or directory: 'I830000_E32_gen.pth'

Maybe you should @MazeOfEncryption

I just got the same error too with the Colab notebook...

I believe this occurs if the input image is not 64x64 images. For the time being, you can use an image editor to crop/resize your input image. As soon as I have time (will probably be a day or two), I'll add something to preprocess input images.

This seems to be an issue with gdown
I'll try to figure out a workaround.

Trying to download the dataset manually gives this issue:

@Janspiry Looks like the pre-trained model files are getting rate limited. Perhaps it would be better to upload the pre-trained model somewhere else? Either in a separate github repo, or on a different file hosting platform, etc.

Oh, I will update it soon. @MazeOfEncryption

Oh, I will update it soon. @MazeOfEncryption

Sounds good! If I were you, I would just make a new GitHub repo for it.

I am getting this error too on the Google Colab.
export CUDA_VISIBLE_DEVICES=0,1
21-11-13 14:56:23.767 - INFO:   name: distributed_high_sr_ffhq
phase: val
gpu_ids: [0, 1]
path:[
log: experiments/distributed_high_sr_ffhq_211113_145623/logs
tb_logger: experiments/distributed_high_sr_ffhq_211113_145623/tb_logger
results: experiments/distributed_high_sr_ffhq_211113_145623/results
checkpoint: experiments/distributed_high_sr_ffhq_211113_145623/checkpoint
resume_state: I830000_E32
experiments_root: experiments/distributed_high_sr_ffhq_211113_145623
]
datasets:[
train:[
name: FFHQ
mode: HR
dataroot: dataset/ffhq_64_512
datatype: img
l_resolution: 64
r_resolution: 512
batch_size: 2
num_workers: 8
use_shuffle: True
data_len: -1
]
val:[
name: CelebaHQ
mode: LRHR
dataroot: dataset/celebahq_64_512
datatype: img
l_resolution: 64
r_resolution: 512
data_len: 50
]
]
model:[
which_model_G: sr3
finetune_norm: False
unet:[
in_channel: 6
out_channel: 3
inner_channel: 64
norm_groups: 16
channel_multiplier: [1, 2, 4, 8, 16]
attn_res: []
res_blocks: 1
dropout: 0
]
beta_schedule:[
train:[
schedule: linear
n_timestep: 2000
linear_start: 1e-06
linear_end: 0.01
]
val:[
schedule: linear
n_timestep: 2000
linear_start: 1e-06
linear_end: 0.01
]
]
diffusion:[
image_size: 512
channels: 3
conditional: True
]
]
train:[
n_iter: 1000000
val_freq: 10000.0
save_checkpoint_freq: 10000.0
print_freq: 50
optimizer:[
type: adam
lr: 3e-06
]
ema_scheduler:[
step_start_ema: 5000
update_ema_every: 1
ema_decay: 0.9999
]
]
distributed: True
21-11-13 14:56:23.774 - INFO: Dataset [LRHRDataset - CelebaHQ] is created.
21-11-13 14:56:23.774 - INFO: Initial Dataset Finished
21-11-13 14:56:40.215 - INFO: Loading pretrained model for G [I830000_E32] ...
Traceback (most recent call last):
File "infer.py", line 46, in
diffusion = Model.create_model(opt)
File "/content/Image-Super-Resolution-via-Iterative-Refinement/model/init.py", line 7, in create_model
m = M(opt)
File "/content/Image-Super-Resolution-via-Iterative-Refinement/model/model.py", line 42, in init
self.load_network()
File "/content/Image-Super-Resolution-via-Iterative-Refinement/model/model.py", line 158, in load_network
gen_path), strict=(not self.opt['model']['finetune_norm']))
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 594, in load
with _open_file_like(f, 'rb') as opened_file:
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 230, in _open_file_like
return _open_file(name_or_buffer, mode)
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 211, in init
super(_open_file, self).init(open(name, mode))
FileNotFoundError: [Errno 2] No such file or directory: 'I830000_E32_gen.pth'

Oh, I will update it soon. @MazeOfEncryption

Sounds good! If I were you, I would just make a new GitHub repo for it.
What can I do in  a new GitHub repo? I didn't try it in the before.

I'm also getting the same error on colab

For me it just works, you need to upload the models to the /content/Image-Super-Resolution-via-Iterative-Refinement/ folder

For me it just works, you need to upload the models to the /content/Image-Super-Resolution-via-Iterative-Refinement/ folder

After this issue was posted, I added a section with instructions for manually uploading the model as a temporary workaround.
In the future this will be fixed, but I'm glad to hear that the workaround works for now.

@Janspiry Actually, after looking into it a bit further, it looks like github has a limit of 100mb for files, and 1gb of storage + 1gb of bandwidth for large file storage, so I would not go that route. I'll see if I can find something else.

@MazeOfEncryption I see, thanks.

I'm not familiar with any public ML model repos but it seems like one of them would be ideal if you're looking for a place to make your model files available.
I noticed on Kaggle apparently some people use their public datasets for pretrained model files - and they appear to have pretty generous  space limits. If you wanted to make a Kaggle Kernel version of the Colab notebook too, that might be a good option.

I found a fairly simple solution but I can't test script because of error in "upscaling" part (at the end).
The steps are as follows:

Adding a shortcut of the "checkpoint" folder with .pth files to your google drive
Mounting the google drive in the colab script:
from google.colab import drive
drive.mount('/content/drive')
Copying the files using the shortcut:
!cp /content/drive/MyDrive/checkpoint/I830000_E32_gen.pth /content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_gen.pth
!cp /content/drive/MyDrive/checkpoint/I830000_E32_opt.pth /content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_opt.pth
(OPTIONAL) Checking the size of the copied files:
import os
print("From Google Drive, file I830000_E32_gen.pth should be about 592.7 MB ")
file_1 = os.stat('/content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_gen.pth').st_size
print(str(file_1) + " B = " + str(file_1/1024/1024) + " MB")
print("From Google Drive, file I830000_E32_opt.pth should be about 1.16 GB ")
file_2 = os.stat('/content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_opt.pth').st_size
print(str(file_2) + " B = " + str(file_2/1024/1024/1024) + " GB")

Please check if this works for you
Error in "Upscaling":
Traceback (most recent call last):
File "infer.py", line 40, in
val_set = Data.create_dataset(dataset_opt, phase)
File "/content/Image-Super-Resolution-via-Iterative-Refinement/data/init.py", line 34, in create_dataset
need_LR=(mode == 'LRHR')
File "/content/Image-Super-Resolution-via-Iterative-Refinement/data/LRHR_dataset.py", line 30, in init
'{}/sr_{}_{}'.format(dataroot, l_resolution, r_resolution))
File "/content/Image-Super-Resolution-via-Iterative-Refinement/data/util.py", line 16, in get_paths_from_images
assert os.path.isdir(path), '{:s} is not a valid directory'.format(path)
AssertionError: dataset/celebahq_64_512/sr_64_512 is not a valid directory

I'm not familiar with any public ML model repos but it seems like one of them would be ideal if you're looking for a place to make your model files available.
I noticed on Kaggle apparently some people use their public datasets for pretrained model files - and they appear to have pretty generous space limits. If you wanted to make a Kaggle Kernel version of the Colab notebook too, that might be a good option.

Thanks a lot for your suggestion, It will be a nice choice.

I found a fairly simple solution but I can't test script because of error in "upscaling" part (at the end).
The steps are as follows:

Adding a shortcut of the "checkpoint" folder with .pth files to your google drive
Mounting the google drive in the colab script:
from google.colab import drive
drive.mount('/content/drive')
Copying the files using the shortcut:
!cp /content/drive/MyDrive/checkpoint/I830000_E32_gen.pth /content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_gen.pth
!cp /content/drive/MyDrive/checkpoint/I830000_E32_opt.pth /content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_opt.pth
(OPTIONAL) Checking the size of the copied files:
import os
print("From Google Drive, file I830000_E32_gen.pth should be about 592.7 MB ")
file_1 = os.stat('/content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_gen.pth').st_size
print(str(file_1) + " B = " + str(file_1/1024/1024) + " MB")
print("From Google Drive, file I830000_E32_opt.pth should be about 1.16 GB ")
file_2 = os.stat('/content/Image-Super-Resolution-via-Iterative-Refinement/I830000_E32_opt.pth').st_size
print(str(file_2) + " B = " + str(file_2/1024/1024/1024) + " GB")

Please check if this works for you
Error in "Upscaling": Traceback (most recent call last): File "infer.py", line 40, in val_set = Data.create_dataset(dataset_opt, phase) File "/content/Image-Super-Resolution-via-Iterative-Refinement/data/init.py", line 34, in create_dataset need_LR=(mode == 'LRHR') File "/content/Image-Super-Resolution-via-Iterative-Refinement/data/LRHR_dataset.py", line 30, in init '{}/sr_{}_{}'.format(dataroot, l_resolution, r_resolution)) File "/content/Image-Super-Resolution-via-Iterative-Refinement/data/util.py", line 16, in get_paths_from_images assert os.path.isdir(path), '{:s} is not a valid directory'.format(path) AssertionError: dataset/celebahq_64_512/sr_64_512 is not a valid directory

I'm getting the same error.

@Samox1 @deama This should be fixed now.
A recent pull request changed the default location to create the dataset folder, which is what caused this problem.

Oh, I will update it soon. @MazeOfEncryption

The problem is that you made the links not able to download by everyone. change the option to "share with everyone"

Oh, I will update it soon. @MazeOfEncryption

The problem is that you made the links not able to download by everyone. change the option to "share with everyone"

No, even if it is set to share with everyone, this issue can occur. It's a known issue with gdown.

@MazeOfEncryption Is the issue fixed? Apparently I still get the same error at the last cell

@MazeOfEncryption Is the issue fixed? Apparently I still get the same error at the last cell

If the gdown command failed, did you try manually uploading the files?

I'm not familiar with any public ML model repos but it seems like one of them would be ideal if you're looking for a place to make your model files available.
I noticed on Kaggle apparently some people use their public datasets for pretrained model files - and they appear to have pretty generous space limits. If you wanted to make a Kaggle Kernel version of the Colab notebook too, that might be a good option.

Thanks a lot for your suggestion, It will be a nice choice.

Yeah, this seems like a good option. It seems more reliable for this sort of thing compared to google drive. It looks like you can just make an account and upload the model files as a "dataset".
Kaggle api comes preinstalled on colab, so it will be quite easy to change the notebook to use it.

Don't know if you guys still looking for a colab solution, but I quickly modified the colab in this fork: https://github.com/bycloudai/ISRIR-colab
It'll mount onto your Google Drive like how @Samox1 suggested. Just need to create a folder in your base Google Drive called "ISRIR" and download & upload the checkpoints to that folder. Remember the mount GDrive step too. Hope this helps.


typo fix

@guanqun I'm sorry for the inconvenience, but could you please merge in the latest master of LightGBM to your branch and push? We recently fixed some issues with our continuous integration that are blocking this PR.

@jameslamb sure. rebased.

@guanqun We are so sorry about that, but could you please do it one more time? We've fixed more CI issues in #3193.


Fix for issue #35: return non-zero on invalid usage

"Invalid usage" meaning missing config file, wrong args, or getopt parse failure.

Thanks!


chore(docs): #9644 Added top position example for ActionBar

Fixes #9644
This MR add example in the demo how to place ActionBar to the top on page
Discussed with @vladimirpotekhin and @waterplea
Example: https://taiga-ui.dev/components/actions-bar#top-position (URL will be available after merge)

One of test have to fail because I add a new test to check if position really on top

Failed tests ❌
Before (main) ← Diff → After (local)
tests-addon-doc-navigation-bbc63-getting-started-light-mode--chromium/01-tui-doc-navigation-light-mode.diff.png

tests-addon-doc-navigation-fa9c7--getting-started-dark-mode--chromium/02-tui-doc-navigation-dark-mode.diff.png

tests-demo-demo.pw-Demo-components-carousel-chromium/components-carousel/3.diff.png

(updated for commit 0ddc6d0)

I suppose it is problem of all PRs?


Atrributes on table being ignored

Hello.
I got class for the table specified the following way:
[Table("Tables")]
public class Table
{
    [PrimaryKey]
    [AutoIncrement]
    [Column("id")]
    public int Id { get; set; }

    public int FirstField { get; set; }

    [NotNull]
    public int SomeField { get; set; }
}

And I use
_db.CreateTableAsync<Table>(); or _db.CreateTable<Table>();
in order to create table.
As the result table being created, but all attributes being ignore.
I use sqlite-net-pcl\1.8.116

My mistake. Everything works fine. Please close the issue.
Thanks for the great project.

Do you remember what the solution was?


Dmp 811 add functional tests for courthouses resource

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

@mmmalik1 These tests were fixed in https://github.com/hmcts/darts-api/pull/587 by @richardbull


cargo bench --features=simd crashes the compiler

I see the following log:
$ multirust run nightly cargo bench --features=simd
   Compiling argon2rs v0.2.1 (file:///Users/upsuper/Sources/argon2rs)
Assertion failed: (ReqTy && "extractvalue indices invalid!"), function getExtractValue, file /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/llvm/lib/IR/Constants.cpp, line 2157.
error: Could not compile `argon2rs`.

Looks like a compiler bug...
My rust version:
$ multirust run nightly rustc --version
rustc 1.10.0-nightly (764ef92ae 2016-05-19)

on OS X 10.10.

Looks like it is from the test module in octword.

Reported rust-lang/rust#33764.

That truly is unfortunate. Nonetheless, nice catch.


An Error ---- 8481 chair thrown when running python sunrgbd_data.py --gen_v1_data

When I run python sunrgbd_data.py --gen_v1_data  to process 10335 data, there is an image that triggers this exception Error ---- 8481 chair  from
if save_votes:
            N = pc_upright_depth_subsampled.shape[0]
            point_votes = np.zeros((N,10)) # 3 votes and 1 vote mask
            point_vote_idx = np.zeros((N)).astype(np.int32) # in the range of [0,2]
            indices = np.arange(N)
            for obj in objects:
                if obj.classname not in type_whitelist: continue
                try:
                    # Find all points in this object's OBB
                    box3d_pts_3d = sunrgbd_utils.my_compute_box_3d(obj.centroid,
                        np.array([obj.l,obj.w,obj.h]), obj.heading_angle)
                    pc_in_box3d,inds = sunrgbd_utils.extract_pc_in_box3d(\
                        pc_upright_depth_subsampled, box3d_pts_3d)
                    # Assign first dimension to indicate it is in an object box
                    point_votes[inds,0] = 1
                    # Add the votes (all 0 if the point is not in any object's OBB)
                    votes = np.expand_dims(obj.centroid,0) - pc_in_box3d[:,0:3]
                    sparse_inds = indices[inds] # turn dense True,False inds to sparse number-wise inds
                    for i in range(len(sparse_inds)):
                        j = sparse_inds[i]
                        point_votes[j, int(point_vote_idx[j]*3+1):int((point_vote_idx[j]+1)*3+1)] = votes[i,:]
                        # Populate votes with the fisrt vote
                        if point_vote_idx[j] == 0:
                            point_votes[j,4:7] = votes[i,:]
                            point_votes[j,7:10] = votes[i,:]
                    point_vote_idx[inds] = np.minimum(2, point_vote_idx[inds]+1)
                except:
                    print('ERROR ----',  data_idx, obj.classname)

All the other images were handled well, do you know what's wrong with it?

I have the same problem as you, not only in 8481 chair but also in 7334 desk.


RM4Pro   typeid 5213 Broadlink: Unconfigured Device Type

{"_msgid":"a9c79a39e8f5695e","payload":[{"mac":"ec0baeee04f1","ip":"x.x.x.x","typeid":"5213","type":"Broadlink: Unconfigured Device Type: Log an issue with the device details and typeid returned as this may be a new device type.","name":"\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0002\u0001E��E\u0002\u0000\u0000\u0000\u0019�\n�B\r\u0000\u0000\u0000","cloud":false,"msgdata":[0,0,0,0,0,0,0,0,253,255,255,255,123,0,8,16,23,5,14,3,0,0,0,0,10,0,30,20,80,186,0,0,29,205,0,0,0,0,7,0,0,0,0,0,0,0,0,0,0,0,0,0,19,82,86,30,0,10,236,11,174,238,4,241,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,1,69,154,154,69,2,0,0,0,25,224,10,231,66,13,0,0,0,0]}],"topic":""}

I have this same new device type:

Looks like it's mine too! Discover doesn't even work for me, but I pip installed broadlink, ran broadlink.discover(), and it showed devtype "21011", which in hex is 5213. Does someone want to fork this and add 5213? Looks like it's only needed in Constants.js and DiscoverNode.js

Discover works now! However, learn and send don't work - not even a message. I followed your resetting and stop at WIFI instructions twice. I even deleted the broadlink app from my iPhone and all data, and still nothing is working. Thoughts? Is there a way I could debug the process to see where the issue is?
Anyone able to get a 5213 to work?

same with 520b


Add localpath utility to docker scripts

❯ pwd
/workspaces/docker-images
❯ localpath "$(pwd)"
/home/felipesantos/repos/docker-images
❯ localpath ..
/home/felipesantos/repos
❯ localpath /tmp
/tmp

Closes https://github.com/microsoft/vscode-dev-containers/issues/508.

I don't think this is a good idea anymore. For those using docker-on-docker (rather than docker-in-docker), I strongely suggest to mount the workspace using the same path as in host with the following:
// devcontainer.json
{
  "workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind,consistency=cached",
  "workspaceFolder": "${localWorkspaceFolder}"
}


decode cid: 160 and 173 to spaces

Looks good, although the title contains a typo (170 instead of 173)

@RolandColored Thank you for the update, fixed the typo. Could u please merge the updates?

@goulu Would u be able to merge these changes?


point travis badge at master

I think it's safe to merge as it is. It looks like the failing Galen test just shifted the pixels over a bit. It happens sometimes.


Should vcpkg install google-cloud-cpp work on Apple M1?

On my Mac mini (M1) I'm starting to see what works and what doesn't. As part of my testing, I'm hitting something funny w/ vcpkg, which I'm not sure if the problem is me, our project, or vcpkg, or something else.
jgm@appleslice ~/vcpkg (master) [1]> ./vcpkg install  google-cloud-cpp
Computing installation plan...
The following packages will be built and installed:
  * abseil[core]:x64-osx -> 2021-03-24
  * c-ares[core]:x64-osx -> 1.17.1#1
  * crc32c[core]:x64-osx -> 1.1.1
  * curl[core,non-http,sectransp,ssl]:x64-osx -> 7.74.0#4
    google-cloud-cpp[core]:x64-osx -> 1.26.0
  * grpc[core]:x64-osx -> 1.37.0
  * nlohmann-json[core]:x64-osx -> 3.9.1
  * openssl[core]:x64-osx -> 1.1.1k
  * protobuf[core]:x64-osx -> 3.15.8
  * re2[core]:x64-osx -> 2020-10-01
  * upb[core]:x64-osx -> 2020-12-19#1
  * zlib[core]:x64-osx -> 1.2.11#10
...
-- Building x64-osx-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:146 (message):
    Command failed: /Users/jgm/vcpkg/downloads/tools/cmake-3.20.1-osx/cmake-3.20.1-macos-universal/CMake.app/Contents/bin/cmake --build . --config Debug --target install -- -v -j9
    Working Directory: /Users/jgm/vcpkg/buildtrees/abseil/x64-osx-dbg
    See logs for more information:
      /Users/jgm/vcpkg/buildtrees/abseil/install-x64-osx-dbg-out.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_build_cmake.cmake:105 (vcpkg_execute_build_process)
  scripts/cmake/vcpkg_install_cmake.cmake:45 (vcpkg_build_cmake)
  ports/abseil/portfile.cmake:32 (vcpkg_install_cmake)
  scripts/ports.cmake:142 (include)

Error: Building package abseil:x64-osx failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `./vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: abseil:x64-osx
  Vcpkg version: 2021-01-13-unknownhash

Additionally, attach any relevant sections from the log files above.

Notice that it's using the triplet of x64-osx, which doesn't seem right. I can explicitly specify the triplet on the command line like this:
jgm@appleslice ~/vcpkg (master) [1]> ./vcpkg install --triplet arm64-osx  google-cloud-cpp
Computing installation plan...
The following packages will be built and installed:
  * abseil[core]:x64-osx -> 2021-03-24
  * c-ares[core]:arm64-osx -> 1.17.1#1
  * c-ares[core]:x64-osx -> 1.17.1#1
  * crc32c[core]:arm64-osx -> 1.1.1
  * curl[core,non-http,sectransp,ssl]:arm64-osx -> 7.74.0#4
    google-cloud-cpp[core]:arm64-osx -> 1.26.0
  * grpc[core]:x64-osx -> 1.37.0
  * grpc[core]:arm64-osx -> 1.37.0
  * nlohmann-json[core]:arm64-osx -> 3.9.1
  * openssl[core]:x64-osx -> 1.1.1k
  * openssl[core]:arm64-osx -> 1.1.1k
  * protobuf[core]:x64-osx -> 3.15.8
  * protobuf[core]:arm64-osx -> 3.15.8
  * re2[core]:x64-osx -> 2020-10-01
  * re2[core]:arm64-osx -> 2020-10-01
  * upb[core]:x64-osx -> 2020-12-19#1
  * upb[core]:arm64-osx -> 2020-12-19#1
  * zlib[core]:arm64-osx -> 1.2.11#10
  * zlib[core]:x64-osx -> 1.2.11#10
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-osx...
Detecting compiler hash for triplet arm64-osx...
...

And that results in the same error. However, notice that it's still pulling Abseil using x64-osx, then it fails w/ the same error, which makes sense.
So, is this an issue w/ vcpkg? Or perhaps w/ the software within vcpkg (i.e., Abseil in this case)? Am I doing something wrong?

Just found https://github.com/microsoft/vcpkg/issues/17436

Looks like the issue may be fixed in https://github.com/microsoft/vcpkg-tool/pull/23, which I don't think has been released yet

It looks like the fix for vcpkg was released in https://github.com/microsoft/vcpkg-tool/releases/tag/2021-05-05-9f849c4c43e50d1b16186ae76681c27b0c1be9d9 and it now works
jgm@appleslice ~/vcpkg (master)> ./vcpkg install  google-cloud-cpp
Computing installation plan...
The following packages will be built and installed:
  * c-ares[core]:arm64-osx -> 1.17.1#1
  * crc32c[core]:arm64-osx -> 1.1.1
  * curl[core,non-http,sectransp,ssl]:arm64-osx -> 7.74.0#7
    google-cloud-cpp[core]:arm64-osx -> 1.27.0
  * grpc[codegen,core]:arm64-osx -> 1.37.0#2
  * nlohmann-json[core]:arm64-osx -> 3.9.1
  * openssl[core]:arm64-osx -> 1.1.1k#3
  * protobuf[core]:arm64-osx -> 3.15.8#1
  * re2[core]:arm64-osx -> 2020-10-01
  * upb[core]:arm64-osx -> 2020-12-19#1
  * zlib[core]:arm64-osx -> 1.2.11#10
...


Various SVG size values are not properly set

Describe the bug
Several of the size values used within the generated SVG images are hardcoded and not based on the passed in size prop. This causes the size of the avatar to not always be respected and can lead to it being rendered blurry.
To Reproduce
Steps to reproduce the behavior:
Step 1: go to https://source.boringavatars.com/marble/120/Maria Mitchell?colors=264653,2a9d8f,e9c46a,f4a261,e76f51
Step 2: View source on the page
Step 3: Notice how the width and height (SIZE) in various places ("Viewbox", "mask", and "rect" for instance) are not 120, but instead are hardcoded to 80
Expected behavior
The user-supplied height is properly applied to the full svg
Screenshots
If applicable, add screenshots to help explain your problem.
Note:
I tried manually editing a saved version of the image and setting all the properties to 120 and it works totally fine.

Hey @marcfrankel, that's right, I'll take a look as soon as I can. Thanks for raising this up

Is there any update on this? I would love to use these in our project. But sadly the images appear very blurry without this change


Envoy proxy memory usage spikes on service deployments

Description:
Using envoy as a proxy for our services. The envoy proxy is running inside a Kubernetes pod along with a service which acts as its control plane. All our services also run in Kubernetes and this envoy proxy acts as an ingress.
We are facing memory usage spikes in the pods where envoy proxy was running. This was happening whenever a new pod of any service was getting added or deleted.

On deeper analysis, I found out that we were updating our envoy config, for every pod addition/removal, which caused these memory spikes.

I did some research and found out that instead of updating the whole config we can just update the Delta. Envoy Documentation
After making these changes, here is what our config looks like (some part of it):
    "dynamic_resources": {
     "lds_config": {
      "api_config_source": {
       "api_type": "DELTA_GRPC",
       "grpc_services": [
        {
         "envoy_grpc": {
          "cluster_name": "metadata_service_xds"
         }
        }
       ],
       "transport_api_version": "V3"
      },
      "resource_api_version": "V3"
     },
     "cds_config": {
      "api_config_source": {
       "api_type": "DELTA_GRPC",
       "grpc_services": [
        {
         "envoy_grpc": {
          "cluster_name": "metadata_service_xds"
         }
        }
       ],
       "transport_api_version": "V3"
      },
      "resource_api_version": "V3"
     }
    },
    "admin": {
     "access_log_path": "/tmp/admin_access.log",
     "address": {
      "socket_address": {
       "address": "<IP_ADDRESS>",
       "port_value": 9901
      }
     }
    }
   }

Config Dump : envoy.json
Now in the envoy logs I can see that we are not updating all the clusters every time a new pod gets added, but I can see that the listeners still gets updated. Could anyone please help me if I am missing something?

Does the memory still behave as above given the switch to delta? It also seems you have quite a bunch of grpc transcoder filters in the same filter chain -- how is it being used?
cc @htuch @adisuissa
A heap profile https://github.com/envoyproxy/envoy/blob/main/bazel/PPROF.md#cpu-or-memory-consumption-testing-with-gperftools-and-pprof would be useful.

Thank you for your response.
Yes, even after switching to delta the memory usage behavior remains same.
Usecase of gRPC Json Transcorder: So we have a lot of services exposing gRPC endpoints. We have a internal tool which our development teams use to query different service endpoints to test etc., that tool doesn't support gRPC endpoints and hence we have these gRPC json transcoder filters for each service.
Do you suggest splitting these gRPC trancoder filters in different filter chains and test?
I will work on getting the heap profile meanwhile.

First I suggest considering using ADS so the listeners and clusters are all passed on a single gRPC stream. Delta will probably still be a better solution.
IIRC listeners should only be updated if there's something different in the listener (i.e., it's hash is different). If listeners are constantly updated, then it may incur additional CPU and memory usage in Envoy (draining listeners).
If it's possible to decouple the listeners and their routes, then sending RDS updates may be beneficial for your use-case.

Here is the heap profile for one of the runs:
heap_profile.tar.gz
Envoy Binary: drive link
Stats:

I ran the test for 15 mins, where I added few pods and removed few pods and envoy memory usage went from 800MB to 2.75 GB. There was no traffic served from the envoy proxy.
Our listener drain timeout is the default setting of 600 secs.In our production environment we generally have deployments every 2-5 mins.
One more thing that I wanted to point out was we were using an older version of envoy before but have upgraded to v1.28.0, even then we are seeing a similar behaviour.
@adisuissa I did made the changes to use ADS but that didn't have any effect on the memory usage. It is till the same.

@adisuissa I did made the changes to use ADS but that didn't have any effect on the memory usage. It is till the same.

The use of ADS won't change much, other than optimize how many streams are created with the management server.
Using RDS (assuming you only need to update these routing table, rather than the listeners) will probably improve some of the memory usage.

I think two config dumps, one before and one after an update, might be useful.

Sure here are the two config dumps. One when envoy memory usage was around 120MB and after scaling up and down few service pods, memory usage went up to 1.5 GB.
envoy-120MB.json
envoy-1.5GB.json

When I look at the diff between the JSON files (e.g. with diff <(jq --sort-keys . envoy-120MB.json) <(jq --sort-keys . envoy-1.5GB.json)), the bulk of the diff seems to be changes to the gRPC transcoder proto descriptors in binary form, i.e. proto_descriptor_bin field.
Is there a reason these are changing?
I can imagine if we keep incrementing the size of the proto descriptor pool in memory over time, this could happen. I'm thinking of a scenario in which there are longer lived connections that are still using the old transcoder filter while the updates occur. This is consistent with a 600 second listener drain and your graphs spiking during rapid LDS update and then memory use dropping back down within the listener drain period when stabilized.
@nareddyt @lizan as CODEOWNERS.

@htuch
I think the command to check diff based on sorting the keys will not give the intended results as the gRPC JSON Transcoder filters are in an array and those won't be sorted.
We are not modifying the proto descriptors unless the underlying service changes its proto definition (which happens not  frequently).
Also, I was able to reproduce this when there was no traffic handled via envoy. I was just scaling up a few pods and memory usage was increasing on an isolated envoy proxy. So the long living connections are non-existent.
I do see logs in envoy about draining filter chains, could those be hanging on to these descriptors

Can you share the heap profile after pprof analysis, as a flamegraph or some kind of percentage breakdown?

Sharing the screenshot of the flamegraph and some other views. I am unsure which one will be more helpful.
Flame Graph:

Tree:

Top:

Not sure which one will be most useful, so sharing whatever I could find. I have also attached envoy binary which I had used to generated the above heap profiles, just in case the above screenshots are not useful and you want to analyze heap profiles by youself.
https://github.com/envoyproxy/envoy/issues/30986#issuecomment-1826740152

Yeah, this confirms the hypothesis that memory is dominated by proto descriptors. I think if you reduce your drain time it should improve. CC @nareddyt @lizan for thoughts on how to improve this as CODEOWNERS, there's probably some smart descriptor sharing / reference counting / keying we could do.

@abhimoondra is each proto descriptor per gRPC-JSON transcoder filter completely different? Looking over envoy-1.5GB.json, the base64 contents do look different, but I'm curious if any large subset of protos are shared by multiple different descriptors.
If all the protos are very different, TBH this looks like intended behavior. Your config of protobuf descriptors serialized & encoded in base64 is 1.5 GB. I'm not surprised that parsing them out to our internal structures results in ~3 GB of memory usage. I'm assuming you're not seeing any memory leaks (where resource usage keeps growing even after stopping updates).
If you do have any underlying protos that are shared between all descriptors, I'd recommend you consolidate all gRPC transcoder config into one single filter. You can use protoc or protobuf toolchains to merge descriptors together. In theory, this should de-duplicate any shared protos in the descriptors, and make your config size much smaller.

@nareddyt each proto descriptor per gRPC-JSON transcoder filter is different. Every service defines it's own proto contract and in our envoy config we store the base64 encoded version of that proto contract. So there are not much shared protos between the filters.
We are not seeing a memory leak rather memory usage spikes, where on deployments we see a spike in memory usage and after some time it subsides (basically when the filter chains have drained).
What I see is that even when there is no change in any of the proto descriptors' content for any of the gRPC-JSON transcoder filters, the memory usage increases. Is this correct behaviour?
Should the memory usage increase even when the proto descriptor content hasn't changed?

@nareddyt could you please share any feedback on this? We are still seeing the issue.

Should the memory usage increase even when the proto descriptor content hasn't changed?

IIUC this is occurring because the entire listener is being re-created with a new config. I think each individual transcoder config doesn't matter - if you change any section of the listener, the entire listener and all filters get re-created (?) Please have other Envoy exports double check me on this.
If that is true, this is expected behavior. During new listener config, a new listener is started with all new transcoder filters. Note the previous transcoder filters still exist for drain-timeout-s. During this time, we basically have duplicate filters, leading to 2x memory usage. After drain-timeout-s elapses, the older transcoder filters are cleaned up and memory usage goes back to normal.
This should be a general Envoy filter problem, not anything specific to the transcoder. It's just visible here because transcoder configs are huge.
Ref: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/draining

Just an update, I implemented a fix on the similar lines of what is mentioned in this talk.
Before triggering an update to the Envoy configuration, I sorted the gRPC JSON transcoder filters according to the service name. This approach appears to have resolved the spikes in memory usage. Instead of observing the addition of new listeners and the draining of old ones with every deployment, I now notice these changes only when there is an actual modification in the proto descriptor (which I think is expected).

Thank you for all your help. @htuch @nareddyt @adisuissa


feat: allow adding more trusted principals to task role

Description
Extra input variable to allow module users to optionally define extra principals that can assume the task role.
Apart from the main module code and documentation, the example is also updated to showcase how the new variable can be used.
Motivation and Context
At the moment, the only trusted entity to assume the task role is the absolute minimum ecs-tasks.amazonaws.com.
However sometimes it's convenient to allow adding more principals.
For example in order to allow easy SSM access into the Fargate task, ssm.amazonaws.com should be trusted too.
Breaking Changes
No breaking changes. Just adding an optional input variable.
How Has This Been Tested?
From my project downstream, I have referenced this PR branch and applied my infrastructure. It works as expected.

Hi @antonbabenko 👋
I would like to test this PR before I mark it as ready for review.
At the moment I am using this module with
source  = "terraform-aws-modules/atlantis/aws"
Is it possible for me to change this source path so I can reference my branch?
I have tried unsuccessfully something like
source = "git::ssh://github.com/parmouraly/terraform-aws-atlantis.git?ref=feature/extra-trusted-entities"
Any help would be appreciated thanks!

Should work like this - source = "git::git@github.com:parmouraly/terraform-aws-atlantis.git?ref=feature/extra-trusted-entities"

@antonbabenko are you waiting anything from me on this or can we merge please?

Thanks!
v2.27.0 has been just released.


[css] fix text color on profile page in dark mode

fix #266 .
This problem is due to an update of css variable naming in GitHub pages.

/approve


Fix occasional loss of error flags in step tabs

Error flags aren't being set properly when clicking on step tabs instead of "Continue" button


Remove unnecessary disabling of Style/RedundantStringEscape rule

Before contributing, please read our contributing guidelines and code of conduct.
Overview
Describe the changes present in the pull request
Submitter Checklist:

[ ] Include a link to the related GitHub issue, if applicable
[ ] Include a security review link, if applicable

Testing
The agent includes a suite of unit and functional tests which should be used to
verify your changes don't break existing functionality. These tests will run with
GitHub Actions when a pull request is made. More details on running the tests locally can be found
here for our unit tests,
and here for our functional tests.
For most contributions it is strongly recommended to add additional tests which
exercise your changes.
Reviewer Checklist

[ ] Perform code review
[ ] Add performance label
[ ] Perform appropriate level of performance testing
[ ] Confirm all checks passed
[ ] Add version label prior to acceptance

Thank you for taking a look at this! I checked out the rubocop output however, and it looks like this line is something we need. Unfortunately, with this change rubocop now outputs
test/new_relic/agent/logging_test.rb:71:52: C: [Correctable] Style/RedundantStringEscape: Redundant escape of   inside string literal.
          'backslash' => "message with a backslash \ ",

Rubocop seems confused and thinks we're trying to escape a space, so it looks like we'll have to leave this part as is. We appreciate checking on this though!


Fix stuck threads in C#

Fixes #1753
Fixes #988

From the test I run, it seems that the threads are not getting stuck anymore.

I5/22/2015 3:17:49 PM<PHONE_NUMBER>62144 src/core/surface/completion_queue.c:225: RETURN_EVENT[0x7fd738005ba0]: QUEUE_SHUTDOWN
I5/22/2015 3:17:49 PM<PHONE_NUMBER>60896 src/core/surface/completion_queue.c:225: RETURN_EVENT[0x7fd738005ba0]: QUEUE_SHUTDOWN
I5/22/2015 3:17:49 PM<PHONE_NUMBER>63392 src/core/surface/completion_queue.c:225: RETURN_EVENT[0x7fd738005ba0]: QUEUE_SHUTDOWN
I5/22/2015 3:17:49 PM<PHONE_NUMBER>73664 src/core/surface/completion_queue.c:225: RETURN_EVENT[0x7fd738005ba0]: QUEUE_SHUTDOWN
Completion queue has shutdown successfully, thread grpc 2 exiting.
Completion queue has shutdown successfully, thread grpc 3 exiting.
Completion queue has shutdown successfully, thread grpc 0 exiting.
Completion queue has shutdown successfully, thread grpc 1 exiting.

Warning: Detected 1 client calls that weren't disposed properly.
Tests run: 7, Errors: 1, Failures: 0, Inconclusive: 0, Time: 0.607404 seconds
Not run: 0, Invalid: 0, Ignored: 0, Skipped: 0
Errors and Failures:

Test Error : math.Tests.MathClientServerTest.DivMany
System.AggregateException : One or more errors occured
----> System.InvalidOperationException : Already halfclosed.
at System.Threading.Tasks.Task.Wait (Int32 millisecondsTimeout, CancellationToken cancellationToken) [0x00000] in :0
at System.Threading.Tasks.Task.Wait () [0x00000] in :0
at math.Tests.MathClientServerTest.DivMany () [0x00000] in :0
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in :0
--InvalidOperationException
at Grpc.Core.Utils.Preconditions.CheckState (Boolean condition, System.String errorMessage) [0x00000] in :0
at Grpc.Core.Internal.AsyncCallBase2[math.DivArgs,math.DivReply].CheckSendingAllowed () [0x00000] in <filename unknown>:0  at Grpc.Core.Internal.AsyncCall2[math.DivArgs,math.DivReply].StartSendCloseFromClient (Grpc.Core.Internal.AsyncCompletionDelegate1 completionDelegate) [0x00000] in <filename unknown>:0  at Grpc.Core.Internal.ClientRequestStream2[math.DivArgs,math.DivReply].CompleteAsync () [0x00000] in :0
at Grpc.Core.Utils.AsyncStreamExtensions+c__async2`1[math.DivArgs].MoveNext () [0x00000] in :0
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.GetResult () [0x00000] in :0
at math.Tests.MathClientServerTest+c__async17.MoveNext () [0x00000] in :0

Stacktrace:
at  <0xffffffff>
at (wrapper managed-to-native) Grpc.Core.Internal.CallSafeHandle.grpcsharp_call_destroy (intptr) <0xffffffff>
at Grpc.Core.Internal.CallSafeHandle.ReleaseHandle () <0x00017>
at System.Runtime.InteropServices.SafeHandle.Finalize () <0x0003d>
at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
/usr/bin/cli() [0x4b73d8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fd74e07b340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7fd74dcdccc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7fd74dce00d8]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgpr.so.0(gpr_mu_lock+0x4a) [0x7fd749d4fe87]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_iomgr_add_delayed_callback+0x4e) [0x7fd749930105]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_iomgr_add_callback+0x28) [0x7fd749930188]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(+0x5a321) [0x7fd749929321]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_child_call_destroy+0x85) [0x7fd74992961a]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(+0x5b3be) [0x7fd74992a3be]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_call_stack_destroy+0x6f) [0x7fd749928cf6]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(+0x6db48) [0x7fd74993cb48]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_call_internal_unref+0x3c) [0x7fd74993cd89]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_call_destroy+0x80) [0x7fd74993ed36]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc_csharp_ext.so(grpcsharp_call_destroy+0x18) [0x7fd749f58387]
[0x40a12e6b]

Just saw the same error with code that doesn't include this change, so it's probably unrelated. Created a separate issue #1734 for this.

Just checked the python travis failure and it looks like this is not a known flake.

Yeah I need to check that

Otherwise looks good.

Wow. (_c_test timed out.)

Restarted the Python test. Trying to reproduce here.

This will need more investigation (Tuesday latest).

@tbetbetbe @jtattermusch @murgatroid99 @stanley-cheung @nathanielmanistaatgoogle @soltanmm
This change removes the grpc_server_shutdown API and mutates grpc_server_shutdown_and_notify to additionally take a completion queue argument. Additionally it introduces a grpc_server_cancel_all_calls API.
Server termination semantics have changed.
Clients of the core API MUST call grpc_server_shutdown_and_notify at least once prior to calling grpc_server_destroy. Additionally, the completion from grpc_server_shutdown_and_notify MUST be consumed from the completion queue prior to calling grpc_server_destroy.
I'm hoping someone from each server-using wrapped language can send me a pull request against this work to move that implementation across.

@soltanmm you've made the last several Python-side-changes-responding-to-C-Core-API-changes and I'd like you to handle this one as well if you've got time in the next two days?

@soltanmm @jtattermusch @tbetbetbe - friendly ping to get an ETA on this - it'll be blocking for me sometime later next week

I have that PR almost ready, but it seems it introduces lots of flakiness.
The one I see most commonly is that server shuts down properly, but I have a streaming call in progress (serverside handler for unknown method) and this one is still in progress and tries to read from the request stream. Instead of getting some meaningful error, grpc_call_start_batch that should initiate the read segfaults. I will investigate more on monday.

I5/29/2015 5:12:54 PM<PHONE_NUMBER>08960 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: OP_COMPLETE: tag:0x7f3db4075f60 OK
I5/29/2015 5:12:54 PM<PHONE_NUMBER>09856 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc1a48a0]: OP_COMPLETE: tag:0x7f3ddc14cdb0 OK
I5/29/2015 5:12:54 PM<PHONE_NUMBER>09856 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc1a48a0]: QUEUE_SHUTDOWN
I5/29/2015 5:12:54 PM<PHONE_NUMBER>05216 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: OP_COMPLETE: tag:0x7f3dcc004c20 ERROR
I5/29/2015 5:12:54 PM<PHONE_NUMBER>05216 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: OP_COMPLETE: tag:0x7f3ddc186fa0 OK
Waiting for GPRC threads to finish.
I5/29/2015 5:12:54 PM<PHONE_NUMBER>03968 src/core/surface/call.c:1198: grpc_call_start_batch(call=0x7f3db80028e0, ops=0x7f3dd77fa2d0, nops=1, tag=0x7f3db40797c0)
I5/29/2015 5:12:54 PM<PHONE_NUMBER>03968 src/core/surface/call.c:1198: ops[0]: RECV_MESSAGE ptr=0x7f3db4079818
I5/29/2015 5:12:54 PM<PHONE_NUMBER>05216 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: OP_COMPLETE: tag:0x7f3db40797c0 OK
I5/29/2015 5:12:54 PM<PHONE_NUMBER>08960 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: OP_COMPLETE: tag:0x7f3db4079320 OK
I5/29/2015 5:12:54 PM<PHONE_NUMBER>07712 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: QUEUE_SHUTDOWN
I5/29/2015 5:12:54 PM<PHONE_NUMBER>06464 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: QUEUE_SHUTDOWN
I5/29/2015 5:12:54 PM<PHONE_NUMBER>08960 src/core/surface/completion_queue.c:226: RETURN_EVENT[0x7f3ddc0b9e20]: QUEUE_SHUTDOWN
Cannot load type 'Grpc.Core.Tests.ClientServerTest+c__async17'
Cannot load type 'Grpc.Core.Tests.ClientServerTest+c__async17'
Cannot load type 'Grpc.Core.Tests.ClientServerTest+c__async17'
Cannot load type 'Grpc.Core.Tests.ClientServerTest+c__async17'
Stacktrace:
at  <0xffffffff>
at (wrapper managed-to-native) Grpc.Core.Internal.CallSafeHandle.grpcsharp_call_recv_message (Grpc.Core.Internal.CallSafeHandle,Grpc.Core.Internal.CompletionCallbackDelegate) <0xffffffff>
at Grpc.Core.Internal.CallSafeHandle.StartReceiveMessage (Grpc.Core.Internal.CompletionCallbackDelegate) <0x0001f>
at Grpc.Core.Internal.AsyncCallBase2.StartReadMessageInternal (Grpc.Core.Internal.AsyncCompletionDelegate1) <0x0008b>
at Grpc.Core.Internal.AsyncCallServer2.StartReadMessage (Grpc.Core.Internal.AsyncCompletionDelegate1) <0x0001b>
at Grpc.Core.Internal.ServerRequestStream2/<MoveNext>c__async0.MoveNext () <0x00167>   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.Start<Grpc.Core.Internal.ServerRequestStream2/<MoveNext>c__async0<byte[], byte[]>> (Grpc.Core.Internal.ServerRequestStream2/c__async0<byte[], byte[]>&) <0x0005b>
at Grpc.Core.Internal.ServerRequestStream2.MoveNext (System.Threading.CancellationToken) <0x00183>   at System.Collections.Generic.AsyncEnumerator.MoveNext<T> (System.Collections.Generic.IAsyncEnumerator1) <0x00040>
at Grpc.Core.Utils.AsyncStreamExtensions/c__async11.MoveNext () <0x0012f>   at (wrapper unbox) Grpc.Core.Utils.AsyncStreamExtensions/<ToList>c__async11<byte[]>.MoveNext () <0xffffffff>
Completion queue has shutdown successfully, thread grpc 2 exiting.
at System.Threading.Tasks.Task.ProcessCompleteDelegates () <0x00057>
at System.Threading.Tasks.Task.Finish () <0x00157>
at System.Threading.Tasks.Task1<bool>.TrySetResult (bool) <0x000c3>   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetResult (bool) <0x00023>
at Grpc.Core.Internal.ServerRequestStream2/<MoveNext>c__async0.MoveNext () <0x003c3>   at (wrapper unbox) Grpc.Core.Internal.ServerRequestStream2/c__async0<byte[], byte[]>.MoveNext () <0xffffffff>
at System.Threading.Tasks.TaskActionInvoker/ActionInvoke.Invoke (System.Threading.Tasks.Task,object,System.Threading.Tasks.Task) <0x0001a>
at System.Threading.Tasks.Task.InnerInvoke () <0x0006c>
at System.Threading.Tasks.Task.ThreadStart () <0x00297>
at System.Threading.Tasks.Task.Execute () <0x00013>
at System.Threading.Tasks.TpScheduler.TaskExecuterCallback (object) <0x00047>
at (wrapper runtime-invoke) .runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
Completion queue has shutdown successfully, thread grpc 3 exiting.
Completion queue has shutdown successfully, thread grpc 0 exiting.
/usr/bin/cli() [0x4b73d8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f3df1aaa340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7f3df170bcc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f3df170f0d8]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_cq_end_op+0xa9) [0x7f3ded3b3671]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(+0x7068e) [0x7f3ded3b168e]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(+0x6e409) [0x7f3ded3af409]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_call_start_ioreq_and_call_back+0x56) [0x7f3ded3b0e67]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc.so.0(grpc_call_start_batch+0x705) [0x7f3ded3b1dc6]
/usr/local/google/home/jtattermusch/github/grpc/libs/dbg/libgrpc_csharp_ext.so(grpcsharp_call_recv_message+0x5c) [0x7f3ded9cbb48]
[0x4139aa41]
I5/29/2015 5:12:54 PM<PHONE_NUMBER>03968 src/core/surface/call.c:1198: grpc_call_start_batch(call=0x7f3db80028e0, ops=0x7f3dd77fa350, nops=1, tag=0x7f3db40a5000)

@tbetbetbe @soltanmm - friendly ping on this (it's starting to be blocking for me)

As a heads up, this is blocking #1577, which in turn blocks #1615, #1888, #1969, and #1970.
I'd like to figure out with folks on Monday how to unblock this.

Please retitle this pull request? @tbetbetbe and I just had a devil of a time finding it.

Renamed.

@nicolasnoble - it's probably safe to start this review
@jtattermusch - can you re-integrate C# changes?

Aye aye.
On Thu, Jun 11, 2015 at 4:28 PM, Craig Tiller<EMAIL_ADDRESS>wrote:

@nicolasnoble https://github.com/nicolasnoble - it's probably safe to
start this review
@jtattermusch https://github.com/jtattermusch - can you re-integrate C#
changes?
—
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/1731#issuecomment-111305732.

Aside from that nit, I didn't spot anything out of whack, and that globally is LGTM.

@soltanmm @jtattermusch - we'll likely need to work together a little today to resolve conflicts.

VERT!


Check view before scrolling

Check before Scrolling (Not required right now)
refer to https://stackoverflow.com/a/49154882/13279920

Not required write now.


Feature: Update for Node LTS

replaced decompress-tarxz with @felipecrs/decompress-tarxz
decompress-tarxz has not been updated for years, and uses a deprecated version of lzma-native which is incompatible with Node LTS
updated chalk to the latest CommonJS compatible version
updated download
updated eslint

this fixes #124 #122 #120 #116 #114

Can we merge this?

Is it possible to merge this change?


TypeError: Cannot read property 'fcm' of undefined (MAC OS system)

Hi Every one I have face this issue in MAC OS . as well as other OS system like window and linux in working fine but i have face this issue in Mac OS. Can you please help me why occure this issue I try to lot but codunt find this issue. Please help me resolve this issue
Thank you !

Hi Every one I have face this issue in MAC OS . as well as other OS system like window and linux in working fine but i have face this issue in Mac OS. Can you please help me why occure this issue I try to lot but codunt find this issue. Please help me resolve this issue

Did you work this issue out? I'm running into the same.


update js to always have a bibnum

implemented in easyscan-project commit https://github.com/Brown-University-Library/easyscan/commit/c4677d52f763b912adb8cefc67deb9e0c65f083b.


Fixed rxjs version

To a certain extent, I can understand the reasons behind locking @angular/* dependencies' versions (though, I wonder why not declaring ranged dependencied, instead). But would someone explain why is rxjs fixed?  It's been targeting 5.1.1, a months old release, since Angular 2.4.8 came out. This is especially intriguing since Angular itself does not lock its rxjs dependency version (it fact, it doesn't for any of its dependecies).
The reason I'm asking is because today, I stumbled upon an issue while using rxjs related to fromPromise input type - which was solved, merged and released in latest 5.4.0. I upgraded my local rxjs version and, while everything worked just fine, npm expectedly complains about a missing peer dependency.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.

Is there something in ionic that would justify forcing this particular version?

Hello, good question! In the past, we did not have all of our deps fixed, but this began to create issues around the latest releases of things having breaking changes or bugs that caused apps created with the ionic-cli to break right out of the box (obviously an issue for developer experience). Because of this, we decided to pin all of our dependencies to specific versions that we had done all of our testing with so that we could be sure that an out of the box ionic app worked as expected. So, while this meant that we would not always be on the latest and greatest by default, we were able to ensure a working experience. Now that things have stabilized in the Angular world, we have been updating dependencies faster and will continue to make sure we keep our deps as close to the latest as possible to get all the latest bug fixes in these libs.

@jgw96 Hello and thanks for taking the time to explain me this!
I understand your points and was expecting something along those lines - but, to be honest, you didn't really answer my question which was:

Is there something in ionic that would justify forcing this particular version?

It seems to me that, in this case, locking seems more like a "conceptual" practice rather than an answering to a practical need. A practice that is hindering development for Ionic users.

@jgw96 Sorry to insist on this, but today this bit me once again. A bug in timeout operator, that was fixed in April and included in a May release of rxjs, had me scratching my head the whole morning.
You should really consider unlocking versions for this case. Or, at the very least, depend on a more recent one?

@jgw96 Is there any update here?  Can't you at lock down to rxjs: ^5.4.0 so that minor patches can be consumed? Or at the very minimum remove the peer dependency so that builds do not break when using a version of rxjs other than 5.4.0.


Dev fix

changed server.js and moved it back into lib
created an index.js entry point file

GREAT SUCCESS!


hmcl: init at <IP_ADDRESS>

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[x] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

please squash commits - see https://stackoverflow.com/a/35704829/13854774

You need to make it so that there is only one commit.

You need to make it so that there is only one commit.

Done. Thanks to @kuresaru.

Please remove   phases = [ "installPhase" ];, it looks like it is still there.
The commit message should be changed to hmcl-bin instead of hmcl.

Try:
git commit --amend -m "hmcl-bin: init at <IP_ADDRESS>"
git push --force-with-lease

to change the commit message and push.

Try:
git commit --amend -m "hmcl-bin: init at <IP_ADDRESS>"
git push --force-with-lease

to change the commit message and push.

Done. Thanks.

GLib-GIO-ERROR **: 23:29:23.141: No GSettings schemas are installed on the system

when trying to select a folder.
Try adding this:
buildInputs = [ (lib.getLib dconf) ];

GLib-GIO-ERROR **: No GSettings schemas are installed on the system

when trying to select a folder. This is same as another java application I added at #193698.
Try adding this: buildInputs = [ (lib.getLib dconf) ];
you need to squash of course

I tried to add it, but the problem is still.

the problem is still.

Did you run from the command line after installing it or from the desktop item? IIUC the desktop item isn't necessarily reloaded.

the problem is still.

Did you run from the command line after installing it or from the desktop item? IIUC the desktop item isn't necessarily reloaded.

Finally I fixed by using wrapGAppsHook.

Result of nixpkgs-review pr 193920 run on x86_64-linux 1

1 package built:

hmcl-bin

Any update on this pr?

Please advise for additional changes you may need...  @fee1-dead  @bobby285271

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1348

and the top-level entry is missing

and the top-level entry is missing

Sorry I forgot, now I added it.

A little suggestion, change the package name from hmcl-bin to hmcl, this is not AUR