Closed Bug 508909 Opened 15 years ago Closed 15 years ago

add hang detection to complement crash reporting - both metrics and detection

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 429592

People

(Reporter: blizzard, Unassigned)

Details

Recent reports from metrics show that we're getting a lot of users frustrated with hangs and confusion around stuck firefox processes. Second, hangs aren't tracked like we track crashes because we don't have the ability to track them. We can catch a clear crash signal but we don't have the ability to tell when Firefox isn't responding to user input. So in this bug I suggest that we figure out how we can do that. Either through a separate watchdog or something else for each platform. If that watchdog process detects a hang (or, really, a very unresponsive app) it can share that data with us as if it were a crash. Along with that we should be ready to capture, measure and mine the data that we receive. Along with this we should be thinking about if we might have a way to handle the firefox failed to shut down and left a stuck process hanging around problem. (I personally see that a _lot_ on windows with 3.5.)
If you're seeing it a lot, can you use the symbol server and windbg to get a stack trace for the stuck process? That would help a ton in figuring out what's causing the problem.
Some enterprising developer might even be able to create an external app that you could run, that would force firefox to crash in a way that the crash reporter picks up, as an easy-to-use interim step before we get real hang detection.
http://www.codeguru.com/Cpp/W-P/dll/article.php/c105 would probably let said enterprising developer inject a tiny DLL on a new thread that triggered the breakpad dump and submission without crashing, and then tear down the thread!
Just FYI, currently the code that is called after the minidump is written launches the crash reporter and exits the app, so you can't submit without taking the app down. Then again, if your app is hung, it might not matter. It should be trivial to use a similar technique to inject a thread that then crashes, which would get us a stack for all threads. The only downside is that the crash signature will be inside the injected thread, and not whatever thread is hung.
(In reply to comment #4) > The only downside is that > the crash signature will be inside the injected thread, and not whatever thread > is hung. That actually might be an upside -- it'll give us an easy way to search for "hung" crash reports vs. normal crashes, until we have some way of differentiating them at submit time.
Dup of bug 429592?
Yeah, I think so.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.