(In reply to Jeff Muizelaar [:jrmuizel] from comment #5) > I had a look at a minidump for `mozilla::LinkedListIterator<T>::operator*` and the crashing instruction is: `mov dword ptr [rsp+44h], eax`. This instruction comes after a `mov dword ptr [rsp+64h], ecx` and a `mov dword ptr [rsp+38h], r9` This is not static. So far I've confirmed three crash locations in four minidumps for this signature: ``` 00007FFD274060A5 45 31 E4 xor r12d,r12d 00007FFD274060A8 31 F6 xor esi,esi 00007FFD274060AA 31 C9 xor ecx,ecx 00007FFD274060AC 31 C0 xor eax,eax 00007FFD274060AE 4C 89 4C 24 38 mov qword ptr [rsp+38h],r9 00007FFD274060B3 89 4C 24 64 mov dword ptr [rsp+64h],ecx 00007FFD274060B7 89 44 24 44 mov dword ptr [rsp+44h],eax // CRASH: 0xFFF...FFF 00007FFD274060BB 44 89 64 24 40 mov dword ptr [rsp+40h],r12d 00007FFD274060C0 89 74 24 54 mov dword ptr [rsp+54h],esi // CRASH: 0xFFF...FFF 00007FFD274060C4 48 89 5C 24 48 mov qword ptr [rsp+48h],rbx 00007FFD274060C9 4C 8B 7B 08 mov r15,qword ptr [rbx+8] // CRASH: 0x000...008 00007FFD274060CD 49 8B 07 mov rax,qword ptr [r15] 00007FFD274060D0 48 8B 80 B0 00 00 00 mov rax,qword ptr [rax+0B0h] ``` In all cases, the crash is reported as an attempt to access an inaccessible memory location. * In the case of the first two locations, with address `0xFFF...FFF`, this is not consistent with the register values reported in the minidump (that is, `rsp` has something that looks reasonable). * In the last case, with address `0x000...008`, `rbx` is reported to have a value of 0, so the crash is what would be expected... except of course that `rbx` probably shouldn't have a value of 0 there, due to the test up at `...66094`. The crash is probably not localized to the point to which it is attributed in the crash dump. Crashes are distributed across several functions in a way which seems consistent with arising *<mumble>*‍ns after something else happens. [Here](https://crash-stats.mozilla.org/search/?cpu_info=%3Dfamily%2023%20model%201%20stepping%201&reason=%3DEXCEPTION_ACCESS_VIOLATION_READ&address=%3D0xffffffffffffffff&product=Firefox&version=106.0&date=%3E%3D2022-10-12T18%3A58%3A00.000Z&date=%3C2022-10-19T18%3A58%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature) is a more extensive crash-stats link, showing that crashes are not limited to a small handful of functions. I haven't looked at many of the crashes yet (so far, only about 10, with a lot of correlation); but those that I have checked seem to have `MakeDisplayItemWithIndex` as their lowest common ancestor in the call stack, and `nsIFrame::BuildDisplayListForChild` as their highest shared ancestor above that.
Bug 1796126 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.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #5) > I had a look at a minidump for `mozilla::LinkedListIterator<T>::operator*` and the crashing instruction is: `mov dword ptr [rsp+44h], eax`. This instruction comes after a `mov dword ptr [rsp+64h], ecx` and a `mov dword ptr [rsp+38h], r9` This is not static. So far I've confirmed three crash locations in four minidumps for this signature: ``` 00007FFD274060A5 45 31 E4 xor r12d,r12d 00007FFD274060A8 31 F6 xor esi,esi 00007FFD274060AA 31 C9 xor ecx,ecx 00007FFD274060AC 31 C0 xor eax,eax 00007FFD274060AE 4C 89 4C 24 38 mov qword ptr [rsp+38h],r9 00007FFD274060B3 89 4C 24 64 mov dword ptr [rsp+64h],ecx 00007FFD274060B7 89 44 24 44 mov dword ptr [rsp+44h],eax // CRASH: 0xFFF...FFF 00007FFD274060BB 44 89 64 24 40 mov dword ptr [rsp+40h],r12d 00007FFD274060C0 89 74 24 54 mov dword ptr [rsp+54h],esi // CRASH: 0xFFF...FFF 00007FFD274060C4 48 89 5C 24 48 mov qword ptr [rsp+48h],rbx 00007FFD274060C9 4C 8B 7B 08 mov r15,qword ptr [rbx+8] // CRASH: 0x000...008 00007FFD274060CD 49 8B 07 mov rax,qword ptr [r15] 00007FFD274060D0 48 8B 80 B0 00 00 00 mov rax,qword ptr [rax+0B0h] ``` In all cases, the crash is reported as an attempt to access an inaccessible memory location. * In the case of the first two locations, with address `0xFFF...FFF`, this is not consistent with the register values reported in the minidump (that is, `rsp` has something that looks reasonable). * In the last case, with address `0x000...008`, `rbx` is reported to have a value of 0, so the crash is what would be expected... except of course that `rbx` probably shouldn't have a value of 0 there, due to the test up at `...66094`. The crash is probably not localized to the point to which it is attributed in the crash dump. Crashes are distributed across several functions in a way which seems consistent with arising *<mumble>*‍ns after something else happens. [Here](https://crash-stats.mozilla.org/search/?cpu_info=%3Dfamily%2023%20model%201%20stepping%201&reason=%3DEXCEPTION_ACCESS_VIOLATION_READ&address=%3D0xffffffffffffffff&product=Firefox&version=106.0&date=%3E%3D2022-10-12T18%3A58%3A00.000Z&date=%3C2022-10-19T18%3A58%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature) is a more extensive crash-stats link, showing that crashes are not limited to a small handful of functions. I haven't looked at many of the crashes yet (so far, only about 10, with a lot of selection-bias-induced correlation); but those that I have checked seem to have `MakeDisplayItemWithIndex` as their lowest common ancestor in the call stack, and `nsIFrame::BuildDisplayListForChild` as their highest shared ancestor above that.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #5) > I had a look at a minidump for `mozilla::LinkedListIterator<T>::operator*` and the crashing instruction is: `mov dword ptr [rsp+44h], eax`. This instruction comes after a `mov dword ptr [rsp+64h], ecx` and a `mov dword ptr [rsp+38h], r9` This is not static. So far I've confirmed three crash locations in four minidumps for this signature: ``` 00007FFD274060A5 45 31 E4 xor r12d,r12d 00007FFD274060A8 31 F6 xor esi,esi 00007FFD274060AA 31 C9 xor ecx,ecx 00007FFD274060AC 31 C0 xor eax,eax 00007FFD274060AE 4C 89 4C 24 38 mov qword ptr [rsp+38h],r9 00007FFD274060B3 89 4C 24 64 mov dword ptr [rsp+64h],ecx 00007FFD274060B7 89 44 24 44 mov dword ptr [rsp+44h],eax // CRASH: 0xFFF...FFF 00007FFD274060BB 44 89 64 24 40 mov dword ptr [rsp+40h],r12d 00007FFD274060C0 89 74 24 54 mov dword ptr [rsp+54h],esi // CRASH: 0xFFF...FFF 00007FFD274060C4 48 89 5C 24 48 mov qword ptr [rsp+48h],rbx 00007FFD274060C9 4C 8B 7B 08 mov r15,qword ptr [rbx+8] // CRASH: 0x000...008 00007FFD274060CD 49 8B 07 mov rax,qword ptr [r15] 00007FFD274060D0 48 8B 80 B0 00 00 00 mov rax,qword ptr [rax+0B0h] ``` In all cases, the crash was reported as an attempt to ~~access~~ (**EDIT:** specifically, _read_) an inaccessible memory location. * In the case of the first two locations, with address `0xFFF...FFF`, this is not consistent with the register values reported in the minidump (that is, `rsp` has something that looks reasonable). (**EDIT:** Also, it's not consistent with the opcodes, which are _writing_ rather than reading.) * In the last case, with address `0x000...008`, `rbx` is reported to have a value of 0, so the crash is what would be expected... except of course that `rbx` probably shouldn't have a value of 0 there, due to the test up at `...6094`. The crash is probably not localized to the point to which it is attributed in the crash dump. Crashes are distributed across several functions in a way which seems consistent with arising *<mumble>*‍ns after something else happens. [Here](https://crash-stats.mozilla.org/search/?cpu_info=%3Dfamily%2023%20model%201%20stepping%201&reason=%3DEXCEPTION_ACCESS_VIOLATION_READ&address=%3D0xffffffffffffffff&product=Firefox&version=106.0&date=%3E%3D2022-10-12T18%3A58%3A00.000Z&date=%3C2022-10-19T18%3A58%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature) is a more extensive crash-stats link, showing that crashes are not limited to a small handful of functions. I haven't looked at many of the crashes yet (so far, only about 10, with a lot of selection-bias-induced correlation); but those that I have checked seem to have `MakeDisplayItemWithIndex` as their lowest common ancestor in the call stack, and `nsIFrame::BuildDisplayListForChild` as their highest shared ancestor above that.