These crashes happen on a page boundary. In fact, the minidump for the crash in comment 0 shows the code actually accesses nearby memory in the prior page, just before the crash address of `0x0000017bb390c000`. Notably, the instructions are: ``` 00007FFB22A5A464 0F E0 01 pavgb mm0,mmword ptr [rcx] 00007FFB22A5A467 0F E0 0C 11 pavgb mm1,mmword ptr [rcx+rdx] 00007FFB22A5A46B 0F E0 14 51 pavgb mm2,mmword ptr [rcx+rdx*2] 00007FFB22A5A46F 42 0F E0 1C 19 pavgb mm3,mmword ptr [rcx+r11] ``` Where `%rcx = 0x0000017BB390B87C`, `%rdx = 0x0000000000000280` and `%r11 = 0000000000000780`. The crash is on the last line. The address `rcx+r11` works out to `0x17bb390bffc`, which is 4 bytes before the crash address of `0x0000017bb390c000`... and the instruction is reading 8 bytes. The other addresses that didn't crash are clearly on the same page as `0x17bb390bffc` -- the page just before the invalid access. Since Shmem can't be asked to allocate memory adjacent to other memory and this code looks to be treating all of this as one block of memory, this may not be about a freed Shmem. This could be a plain old buffer overrun. Our Shmems are bigger without bug 1757802's patch -- at least by 4 bytes since they would stick a [4-byte size at the end of the block](https://searchfox.org/mozilla-central/rev/301e9545863b14ff85aa110fabd4274da4593f9d/ipc/glue/Shmem.cpp#400). I don't think the size field is used outside of debug builds so the codec could just be stomping on it and we don't notice.
Bug 1765480 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
These crashes happen on a page boundary. In fact, the minidump for the crash in comment 0 shows the code actually accesses nearby memory in the prior page, just before the crash address of `0x0000017bb390c000`. Notably, the instructions are: ``` 00007FFB22A5A464 0F E0 01 pavgb mm0,mmword ptr [rcx] 00007FFB22A5A467 0F E0 0C 11 pavgb mm1,mmword ptr [rcx+rdx] 00007FFB22A5A46B 0F E0 14 51 pavgb mm2,mmword ptr [rcx+rdx*2] 00007FFB22A5A46F 42 0F E0 1C 19 pavgb mm3,mmword ptr [rcx+r11] ``` Where `%rcx = 0x0000017BB390B87C`, `%rdx = 0x0000000000000280` and `%r11 = 0000000000000780`. The crash is on the last line. The address `rcx+r11` works out to `0x17bb390bffc`, which is 4 bytes before the crash address of `0x0000017bb390c000`... and the instruction is reading 8 bytes. The other addresses that didn't crash are clearly on the same page as `0x17bb390bffc` -- the page just before the invalid access. Since Shmem can't be asked to allocate memory adjacent to other memory and this code looks to be treating all of this as one block of memory, this may not be about a freed Shmem. This could be something else. Our Shmems are bigger without bug 1757802's patch -- at least by 4 bytes since they would stick a [4-byte size at the end of the block](https://searchfox.org/mozilla-central/rev/301e9545863b14ff85aa110fabd4274da4593f9d/ipc/glue/Shmem.cpp#400). I don't think the size field is used outside of debug builds so the codec could just be stomping on it and we don't notice.
These crashes happen on a page boundary. In fact, the minidump for the crash in comment 0 shows the code actually accesses nearby memory in the prior page, just before the crash address of `0x0000017bb390c000`. Notably, the instructions are: ``` 00007FFB22A5A464 0F E0 01 pavgb mm0,mmword ptr [rcx] 00007FFB22A5A467 0F E0 0C 11 pavgb mm1,mmword ptr [rcx+rdx] 00007FFB22A5A46B 0F E0 14 51 pavgb mm2,mmword ptr [rcx+rdx*2] 00007FFB22A5A46F 42 0F E0 1C 19 pavgb mm3,mmword ptr [rcx+r11] ``` Where `%rcx = 0x0000017BB390B87C`, `%rdx = 0x0000000000000280` and `%r11 = 0000000000000780`. The crash is on the last line. The address `rcx+r11` works out to `0x17bb390bffc`, which is 4 bytes before the crash address of `0x0000017bb390c000`... and the instruction is reading 8 bytes. The other addresses that didn't crash are clearly on the same page as `0x17bb390bffc` -- the page just before the invalid access. Since Shmem can't be asked to allocate memory adjacent to other memory and this code looks to be treating all of this as one block of memory, this may not be about a freed Shmem. Our Shmems are bigger without bug 1757802's patch -- at least by 4 bytes since they would stick a [4-byte size at the end of the block](https://searchfox.org/mozilla-central/rev/301e9545863b14ff85aa110fabd4274da4593f9d/ipc/glue/Shmem.cpp#400). I don't think the size field is used outside of debug builds so the codec could just be stomping on it and we don't notice.
These crashes happen on a page boundary. In fact, the minidump for the crash in comment 0 shows the code actually accesses nearby memory in the prior page, just before the crash address of `0x0000017bb390c000`. Notably, the instructions are: ``` 00007FFB22A5A464 0F E0 01 pavgb mm0,mmword ptr [rcx] 00007FFB22A5A467 0F E0 0C 11 pavgb mm1,mmword ptr [rcx+rdx] 00007FFB22A5A46B 0F E0 14 51 pavgb mm2,mmword ptr [rcx+rdx*2] 00007FFB22A5A46F 42 0F E0 1C 19 pavgb mm3,mmword ptr [rcx+r11] ``` Where `%rcx = 0x0000017BB390B87C`, `%rdx = 0x0000000000000280` and `%r11 = 0000000000000780`. The crash is on the last line. The address `rcx+r11` works out to `0x17bb390bffc`, which is 4 bytes before the crash address of `0x0000017bb390c000`... and the instruction is reading 8 bytes. The other addresses that didn't crash are clearly on the same page as `0x17bb390bffc` -- the page just before the invalid access. Since Shmem can't be asked to allocate memory adjacent to other memory and this code looks to be treating all of this as one block of memory, this may not be about a freed Shmem. Our Shmems are bigger without bug 1757802's patch -- at least by 4 bytes since they would stick a [4-byte size at the end of the block](https://searchfox.org/mozilla-central/rev/301e9545863b14ff85aa110fabd4274da4593f9d/ipc/glue/Shmem.cpp#400). I don't think the size field is used outside of debug builds so the codec could just be ~~stomping on it~~ using garbage (it's a read access) and we don't notice.