Remove intermediary buffers in MozStackWalkThread
Categories
(Core :: mozglue, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox90 | --- | fixed |
People
(Reporter: mozbugz, Assigned: mozbugz)
References
Details
Attachments
(3 files)
Currently MozStackWalkThread uses on-stack buffers to get stack frames from the static function WalkStackMain64, then if the buffers were too small it resizes them on the stack and calls WalkStackMain64 again, and finally iterates through the buffers and invokes the user's callback for each frame.
This is quite convoluted, and I don't see the reason not to invoke the callback straight from the stack-walking code, so we wouldn't need these temporary expandable buffers.
Maybe historically there was some critical code where it would be dangerous to call arbitrary callbacks? Mike, would you know? (I will r? you anyway, you may comment then...)
| Assignee | ||
Comment 1•4 years ago
|
||
Depends on D112168
| Assignee | ||
Comment 2•4 years ago
|
||
Depends on D112169
| Assignee | ||
Comment 3•4 years ago
|
||
Depends on D112170
Comment 4•4 years ago
|
||
| thankyou | ||
So, the current complexity is a result of the history of this file. WalkStackMain64's lineage goes back to DumpStackToFileThread, which was added in bug 297723 to apparently fix problems on Windows XP.
Bug 391321 did some more because of dead locks if you got stack traces during static initialization.
The whole "send a message to a dedicated thread in order for it to stack walk" deal was removed in bug 1452204, but a lot of the complexity remained.
I'll need to do another pass, but at quick glance, this looks like a good cleanup.
| Assignee | ||
Updated•4 years ago
|
Comment 6•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/2641848b9639
https://hg.mozilla.org/mozilla-central/rev/22e0032fcbbf
https://hg.mozilla.org/mozilla-central/rev/94b3a2ab4ffa
Description
•