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)

Version 3
defect

Tracking

(Not tracked)

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#323

In 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 0

I 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 file

I 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.

Severity: -- → S4
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.