Open
Bug 1636022
Opened 5 years ago
Updated 5 years ago
Inappropriate PROCESS-CRASH output for killed processes without a crashing thread
Categories
(Testing :: Mozbase, defect, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: whimboo, Unassigned)
References
Details
(In reply to Geoff Brown [:gbrown] from bug 1634035 comment #5)
"application crashed [xxx]" is generated by mozcrash, which tries to set xxx to the top function of the crashing thread. It looks for "(crashed)" to find the crashing thread, then parses that stack:
https://searchfox.org/mozilla-central/rev/7908ce29657cfd623993046bd8e38664e1c0b28e/testing/mozbase/mozcrash/mozcrash/mozcrash.py#323In comment 0, there is no crashing thread:
[task 2020-04-29T13:06:21.385Z] 13:06:21 INFO - No crash [task 2020-04-29T13:06:21.385Z] 13:06:21 INFO - Process uptime: 8 seconds [task 2020-04-29T13:06:21.385Z] 13:06:21 INFO - Thread 0I think that "No crash" condition is a consequence of the way the process was terminated:
[task 2020-04-29T13:06:14.775Z] 13:06:14 INFO - Browser shutdown timed out after 5 seconds, killing process. [task 2020-04-29T13:06:14.775Z] 13:06:14 INFO - Launcher process psutil.Process(pid=6644L, name='firefox.exe', started='13:06:06') detected. Killing parent process psutil.Process(pid=3948, name='firefox.exe', started='13:06:06') instead. [task 2020-04-29T13:06:14.775Z] 13:06:14 INFO - Killing psutil.Process(pid=3948, name='firefox.exe', started='13:06:06') and writing a minidump fileI think that might be the best we can do: If the browser didn't crash but was killed for timeout, it probably isn't helpful to blame any particular thread or associated stack.
Updated•5 years ago
|
Severity: -- → S4
Priority: -- → P3
You need to log in
before you can comment on or make changes to this bug.
Description
•