xpcshell timeout profiles can be truncated or lost when the scheduled dump is killed mid-write
Categories
(Core :: Gecko Profiler, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox154 | --- | fixed |
People
(Reporter: florian, Assigned: florian)
References
Details
(Whiteboard: [fp])
Attachments
(4 files)
With the Gecko profiler running by default, an xpcshell test that times out (typically a shutdown hang) should leave a complete, parseable profile so the hang is diagnosable. The scheduled off-main-thread timeout dump added in bug 2050049 (profiler_schedule_dump_to_file / nsIProfiler.scheduleDumpToFile) is written by the profiler's sampler thread, and two things can prevent a complete profile from reaching the artifacts:
- The xpcshell harness (
runxpcshelltests.py) can force-kill the process while the sampler thread is still writing, uploading truncated (unparseable) JSON. - Fatal-abort paths --
AsyncShutdown'sgDebug.abortand thensTerminatorwatchdog -- can crash the process mid-write.
The profile file also stays flat at ~350 KB during the slow in-memory "threads" build (everything is spliced into the output only at the end), so its size is not a usable progress signal for deciding whether to keep waiting.
Planned work:
- Dump at the full test timeout and move the harness safety-net kill to 150% of the timeout, widening the window the dump has to complete.
- Have the sampler thread exit the process as soon as the scheduled dump is fully written (
aExitAfterDump), so a timed out test ends promptly instead of sitting idle until the 150% safety-net kill. - Let fatal-abort paths wait for an in-progress scheduled dump (
profiler_wait_for_scheduled_dump/nsIProfiler.waitForScheduledDump) instead of crashing over a half-written profile. - Report the dump's 0..1 streaming progress via a
<profile>.progresssidecar file (fed by the profiler'sProgressLogger/SharedProgress) so the harness defers its kill while progress advances and only kills on a genuine stall.
| Assignee | ||
Comment 1•28 days ago
|
||
| Assignee | ||
Comment 2•28 days ago
|
||
| Assignee | ||
Comment 3•28 days ago
|
||
| Assignee | ||
Comment 4•28 days ago
|
||
| Assignee | ||
Comment 5•28 days ago
•
|
||
Try push with the patches on a set of tests and a configuration (profiler sampling all threads) where the profiles were consistently truncated without the patches: https://treeherder.mozilla.org/jobs?repo=try&revision=83362d90e731660503e6dccc3ee69714638907c2
All profiles now seem valid.
A larger try push of all xpcshell tests: https://treeherder.mozilla.org/jobs?repo=try&revision=888868794818eda0042819aa8afbe08aba64c452
Updated•23 days ago
|
Updated•23 days ago
|
Comment 6•22 days ago
|
||
I haven't looked at the patches yet, but my inclination is to avoid the file and reduce complexity. What we're doing here is:
- Trigger a profile dump at 100% of the timeout
- Definitely kill the browser at 150% of timeout + 5 minutes
- Don't wait the entire max time if profile dumping completes earlier
- Don't wait the entire max time if profile dumping is hanging (makes no progress)
1 and 2 sound good. We could do 3 by killing the browser from within Firefox once we're done with dumping the profile. And maybe 4 isn't that important? If we can discard 4 then we don't need the file.
I'll look at the patches now to see how much complexity this would actually avoid.
https://hg.mozilla.org/mozilla-central/rev/80558d586e12
https://hg.mozilla.org/mozilla-central/rev/18a7895dd488
https://hg.mozilla.org/mozilla-central/rev/48184b06a4ea
https://hg.mozilla.org/mozilla-central/rev/f2259ca5ffac
https://hg.mozilla.org/mozilla-central/rev/b5d85ec10416
https://hg.mozilla.org/mozilla-central/rev/ac4407ac1dcf
https://hg.mozilla.org/mozilla-central/rev/d336ab1b50d3
https://hg.mozilla.org/mozilla-central/rev/b5a72f733905
Updated•6 days ago
|
Description
•