Opened 10 years ago
Closed 10 years ago
#11411 closed bug (fixed)
Debugger doesn't exit after saving report.
| Reported by: | pulkomandy | Owned by: | anevilyak |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Applications/Debugger | Version: | R1/Development |
| Keywords: | Cc: | jessicah | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
This seems to be reproductible by running the WebKit testsuite. debug_server is set to automatically save reports rather than prompting the user for what to do.
The report is saved but Debugger doesn't exit after doing so. After a while (about 22000 tests run) my system is out of memory because of all the leftover Debugger instances, and the testsuite stops.
Attaching the DumpRenderTree report that was saved (in case it matters) and matching debug report from the "dead" Debugger with all threads debugged.
Attachments (3)
Change History (10)
by , 10 years ago
| Attachment: | Debugger-16205-debug-04-11-2014-06-59-22.report added |
|---|
by , 10 years ago
| Attachment: | DumpRenderTree-9829-debug-03-11-2014-20-07-29.report added |
|---|
comment:1 by , 10 years ago
comment:3 by , 10 years ago
Replying to axeld:
A benaphore, maybe?
It is a BLocker, so yes. By the looks of things it got as far as calling acquire_sem_etc() though, where I would expect the count of the associated semaphore to be -1 at this point, which it isn't. Am I wrong? (The semaphore in question is: 109500 0 16206 team lock )
comment:4 by , 10 years ago
just for the record: it happens also for me. When I save the debug report for any application which crashes, the debugger won't exit, and will create multiple instances for any app which crashes. So I have to manually kill these instances using ProcessController. Look at the attached screenshot "debugger_instances.png"
by , 10 years ago
| Attachment: | debugger_instances.png added |
|---|
comment:6 by , 10 years ago
| Cc: | added |
|---|
comment:7 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | in-progress → closed |
Should be fixed in hrev48222.
Not quite sure what to make of this one right now. Generating the report completed successfully, and we're waiting for TeamDebugger to terminate the target team. However, that one appears to be waiting to acquire the team lock in order to save settings, which, based on the semaphore counts, in the report, should succeed. Will have to see if I can replicate this one. Out of interest, though it theoretically shouldn't matter, if you have debug_server set to prompt, and pick save manually, do the instances go away, or do they hang in that instance as well?