https://crash-stats.mozilla.org/report/index/8a1143fa-a674-48cd-8603-b865d0211228 is not properly unwound
Categories
(Socorro :: Processor, defect)
Tracking
(Not tracked)
People
(Reporter: jrmuizel, Unassigned)
References
Details
https://crash-stats.mozilla.org/report/index/8a1143fa-a674-48cd-8603-b865d0211228
gives crossbeam_channel::context::Context::with::{{closure}} as the last frame which is very likely wrong.
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 1•3 years ago
|
||
During scanning we get 00007f1100000009 crossbeam_channel::context::Context::with::{{closure}} from the stack when we should probably be getting 00007f110951b163 libgobject-2.0.so.0 + 0x35162 which is the address after it.
00007f1100000009 is probably a remnant of a real address on the stack that had the bottom half clobbered with an integer value.
|
|
Reporter | |
Comment 2•3 years ago
|
||
We could probably avoid this false positive by disassembling backwards from the return address 00007f1100000009 to verify that there's a call instruction there like dbghelp does.
|
|
Reporter | |
Comment 3•3 years ago
|
||
Alternatively or additionally, we could check what CFI caller evaluates to. In this case it ends up as 0 which terminates the stack walk. If we get a 0 and there's lots of stack left we're probably not done.
|
||
Comment 4•3 years ago
|
||
Out of curiosity, I disabled the setting that makes us consider cfi=0 a positive finish, and I got this result (registers hastily stripped). Is this more coherent/useful, or just ultimately still more garbage?
Thread 0 (crashed)
0 libglib-2.0.so.0 + 0x208ed
ResolvedVar
Found by: given as instruction pointer in context
1 libglib-2.0.so.0 + 0x2e86e
Found by: stack scanning
2 libxul.so!_fini + 0x2d0f8df
Found by: stack scanning
3 libxul.so!_fini + 0x2d0f8df
Found by: stack scanning
4 libxul.so!_fini + 0x2d0f8ef
Found by: stack scanning
5 libxul.so!widget_unrealize_cb(_GtkWidget*) [nsWindow.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 7488 + 0x1b6]
Found by: stack scanning
6 libgobject-2.0.so.0 + 0x103b7
Found by: call frame info
7 libglib-2.0.so.0 + 0x38558
Found by: stack scanning
8 libgobject-2.0.so.0 + 0x21d3c
Found by: stack scanning
9 libxul.so!crossbeam_channel::context::Context::with::{{closure}} [context.rs:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 50 + 0x143]
Found by: stack scanning
10 libgobject-2.0.so.0 + 0x35162
Found by: stack scanning
11 libgobject-2.0.so.0 + 0x14a83
Found by: stack scanning
12 libgobject-2.0.so.0 + 0x35347
Found by: stack scanning
13 libgobject-2.0.so.0 + 0x3fa2f
Found by: stack scanning
14 libgobject-2.0.so.0 + 0x29a28
Found by: stack scanning
15 libglib-2.0.so.0 + 0x8aaa0
Found by: stack scanning
16 libgobject-2.0.so.0 + 0x291ed
Found by: stack scanning
17 libgobject-2.0.so.0 + 0x29ce1
Found by: stack scanning
18 libxul.so!_fini + 0x2d0f8df
Found by: stack scanning
19 libgobject-2.0.so.0 + 0x29ce1
Found by: stack scanning
20 libgtk-3.so.0 + 0x3e8fb9
Found by: stack scanning
21 libgtk-3.so.0 + 0x3e8fb9
Found by: stack scanning
22 libglib-2.0.so.0 + 0x58261
Found by: stack scanning
23 libgobject-2.0.so.0 + 0x14724
Found by: stack scanning
24 libgtk-3.so.0 + 0x3e8fb9
Found by: stack scanning
25 libgobject-2.0.so.0 + 0x14c7d
Found by: stack scanning
26 libgobject-2.0.so.0 + 0x16c6b
Found by: stack scanning
27 libgtk-3.so.0 + 0x2d5bf0
Found by: stack scanning
28 libgtk-3.so.0 + 0x2d5d17
Found by: stack scanning
29 libxul.so!_fini + 0x2d0f8ef
Found by: stack scanning
30 libgobject-2.0.so.0 + 0x16acf
Found by: stack scanning
31 libxul.so!nsWindow::Destroy() [nsWindow.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 705 + 0xc]
Found by: stack scanning
32 libxul.so!DestroyWidgetRunnable::Run() [nsView.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 120 + 0x9]
Found by: call frame info
33 libxul.so!mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [TaskController.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 771 + 0x2e]
Found by: call frame info
34 libxul.so!NS_ProcessNextEvent(nsIThread*, bool) [nsThreadUtils.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 467 + 0xd0d]
Found by: call frame info
35 libxul.so!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) [MessagePump.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 85 + 0x6]
Found by: call frame info
36 libxul.so!MessageLoop::Run() [message_loop.cc:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 306 + 0xb]
Found by: call frame info
37 libxul.so!nsBaseAppShell::Run() [nsBaseAppShell.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 137 + 0xc]
Found by: call frame info
38 libxul.so!nsAppStartup::Run() [nsAppStartup.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 295 + 0x9]
Found by: call frame info
39 libxul.so!XREMain::XRE_mainRun() [nsAppRunner.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 5293 + 0xa]
Found by: call frame info
40 libxul.so!XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) [nsAppRunner.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 5478 + 0x7]
Found by: call frame info
41 libxul.so!XRE_main(int, char**, mozilla::BootstrapConfig const&) [nsAppRunner.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 5537 + 0xf]
Found by: call frame info
42 firefox-bin!main [nsBrowserApp.cpp:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 395 + 0x93]
Found by: call frame info
43 libc.so.6 + 0x21f44
Found by: call frame info
44 firefox-bin!frame_dummy + 0xf
Found by: stack scanning
45 firefox-bin!double_conversion::FastDtoa(double, double_conversion::FastDtoaMode, int, double_conversion::Vector<char>, int*, int*) [fast-dtoa.cc:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 652 + 0x16]
Found by: stack scanning
46 firefox-bin + 0x9745f
Found by: stack scanning
47 firefox-bin!double_conversion::FastDtoa(double, double_conversion::FastDtoaMode, int, double_conversion::Vector<char>, int*, int*) [fast-dtoa.cc:1ff2cec0bb36e389df1a209a9f882b443ed48495 : 652 + 0x16]
Found by: stack scanning
48 firefox-bin!_start + 0x28
Found by: stack scanning
|
|
Reporter | |
Comment 5•3 years ago
|
||
That stack is mostly correct and definitely preferred over the original.
See https://crash-stats.mozilla.org/report/index/f1f9c47a-d79c-47ea-93a1-bbc490211230 for the same crash without the unlucky data on the stack.
|
||
Comment 6•3 years ago
|
||
The crash reports this talks about have expired. Additionally, a bunch of things have changed in rust-minidump. I think if this is still a problem, someone should write up an issue in rust-minidump and it can get worked on there.
|
|
Reporter | |
Comment 7•3 years ago
|
||
|
|
Reporter | |
Comment 8•3 years ago
|
||
|
|
||
Comment 9•3 years ago
|
||
Thank you!
|
||
Comment 10•3 years ago
|
||
I verified that this is still an issue, I tried processing this crash and the stack is still truncated. I'll save the raw dump and symbols in order to be able to fix the issues Jeff filed.
Description
•