Open
Bug 1449576
Opened 7 years ago
Updated 1 year ago
Missing crash stack from intermittent timeout in bug 1441580
Categories
(Testing :: Reftest, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: ahal, Unassigned)
References
Details
Attachments
(1 obsolete file)
There's an intermittent reftest startup hang in bug 1441580. We should be killing the process and producing a minidump but for some reason that isn't happening.
Reporter | ||
Comment 1•7 years ago
|
||
Here's an example log:
https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-inbound&job_id=170601870&lineNumber=1635
The 'crashinject: exit 0' line tells me that we're at least hitting killAndGetStack and it returns 0:
https://dxr.mozilla.org/mozilla-central/source/layout/tools/reftest/runreftest.py#663
So possibly we just need to call check_for_crashes. Maybe this was a regression from run-by-manifest.
Reporter | ||
Comment 2•7 years ago
|
||
Nvm, checking for crashes should work properly.
The real reason appears to be that 'crashinject' isn't killing the browser. Notice that after the crashinject status comes back there's a 15 minute timeout followed by a mozprocess timeout error. If crashinject had worked, then mozprocess would return right away.
Reporter | ||
Comment 3•7 years ago
|
||
Wonder if this is also a manifestation of bug 1378743. Maybe on Linux/OSX the stack still gets reported but on Windows it doesn't?
See Also: → 1378743
Comment 4•7 years ago
|
||
(In reply to Andrew Halberstadt [:ahal] from comment #0)
> There's an intermittent reftest startup hang in bug 1441580. We should be
> killing the process and producing a minidump but for some reason that isn't
> happening.
Please note that the hang is no longer visible since the generic worker has been upgraded on Windows. So it might be even harder to reproduce it now.
Updated•2 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Attachment #9383326 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•