Opened 8 years ago
Closed 8 years ago
#13082 closed bug (fixed)
Debugger crash in Thread::IsMainThread
Reported by: | vidrep | Owned by: | anevilyak |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications/Debugger | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #13109 | |
Platform: | All |
Description
hrev50701 x86_gcc2 Open YouTube video After a couple of minutes Webpositive crashed followed immediately by a Debugger crash. Debugger crash report attached
Attachments (12)
Change History (36)
by , 8 years ago
Attachment: | Debugger-3124-debug-18-11-2016-16-27-51.report added |
---|
by , 8 years ago
Attachment: | WebPositive-2023-debug-18-11-2016-16-27-39.report added |
---|
by , 8 years ago
comment:2 by , 8 years ago
Summary: | Debugger crash → Debugger crash in Thread::IsMainThread |
---|
follow-up: 4 comment:3 by , 8 years ago
Sounds possibly related to #12155, but it's a case where it's difficult to tell what really went wrong without more detail. This might be one of those issues that'd be more readily analyzed once Ingo's core file support is a bit more complete.
follow-up: 5 comment:4 by , 8 years ago
Replying to anevilyak:
This might be one of those issues that'd be more readily analyzed once Ingo's core file support is a bit more complete.
AFAIK the only thing that really needs to be done is to enforce some GUI restrictions in core dump mode (disabling stepping/running, setting breakpoints, editing memory). Other than that there are a few TODOs left in the code, but those are referring to cosmetic issues (e.g. implementing CoreFileDebuggerInterface::GetSymbolInfo()
would only be for sake of completeness, as it isn't actually used anywhere ATM (save for TeamDebugger
finding the main
symbol before resuming a debuggee)).
IOW, it should all work, just don't press any of those buttons that should be disabled (I guess nothing will happen anyway) ;-).
follow-up: 6 comment:5 by , 8 years ago
Replying to bonefish:
IOW, it should all work, just don't press any of those buttons that should be disabled (I guess nothing will happen anyway) ;-).
It's been a while since I tried, but I thought resolving addresses to symbols wasn't implemented yet, ergo stack traces only show addresses rather than function names. Was that already taken care of?
comment:6 by , 8 years ago
Replying to anevilyak:
It's been a while since I tried, but I thought resolving addresses to symbols wasn't implemented yet, ergo stack traces only show addresses rather than function names. Was that already taken care of?
AFAICT changeset 6c06458f8aacc77038c39e24ae2ecb04a2dc7186 completed the symbol support. I don't recall the details, but I assume I did even test it. ;-) If anything isn't working yet, please file a ticket (not sure when I'll get to it, though).
comment:7 by , 8 years ago
hrev50749 x86_gcc2 Had a simultaneous crash of Web+ and debugger while loading Haiku IRC logs page. I have attached both debugger reports and syslog.
by , 8 years ago
Attachment: | Debugger-577-debug-08-12-2016-10-41-18.report added |
---|
by , 8 years ago
Attachment: | WebPositive-520-debug-08-12-2016-10-41-11.report added |
---|
by , 8 years ago
by , 8 years ago
Attachment: | WebPositive-1230-debug-08-12-2016-11-06-14.report added |
---|
comment:9 by , 8 years ago
Looks to be a slightly different crash from the first. As best I can tell, for the original crash, the Thread object being queried has already been deleted, which is probably a result of someone not acquiring a reference to it when they should.
The new crash appears to be related to releasing the wait semaphore too often, will need to look into that further since it may be a result of my changes the other night. In any case, the Web+ crashes deserve their own ticket, since they're unrelated to the debugger trying to generate a report for them.
comment:11 by , 8 years ago
Thanks. For reference as far as trying to replicate this at home, is any site in particular relatively consistently producing this situation for you (web+ crash -> debugger crash that is), or does it seem entirely random?
follow-up: 13 comment:12 by , 8 years ago
Two of the 3 crashes are while playing HTML5 videos. I think going to youtube and closing the tab or window while the video is playing may be a good way to trigger this.
comment:13 by , 8 years ago
Replying to pulkomandy:
Two of the 3 crashes are while playing HTML5 videos. I think going to youtube and closing the tab or window while the video is playing may be a good way to trigger this.
OK, thanks. Will try to find time to dig into it this weekend, though I have some suspicions already.
comment:14 by , 8 years ago
comment:16 by , 8 years ago
Actually it winds up referencing both, a typo on my part at the end. Too late to fix that how in any case.
comment:17 by , 8 years ago
hrev50754 x86_gcc2 While looking at trac tickets I had back-to-back Web+ crashes, with a debugger crash following immediately after. I have attached all three debugger reports and the syslog from that browsing session (2 Web+, 1 Debugger, 1 syslog)
by , 8 years ago
Attachment: | Debugger-1933-debug-11-12-2016-01-37-43.report added |
---|
by , 8 years ago
Attachment: | WebPositive-1141-debug-11-12-2016-01-26-04.report added |
---|
by , 8 years ago
Attachment: | WebPositive-1732-debug-11-12-2016-01-37-34.report added |
---|
by , 8 years ago
comment:18 by , 8 years ago
Are you building Haiku yourself, or using prebuilt images? Since you seem to be able to reproduce this situation so easily, it would be convenient if you could enable debug for the folders 'src kits debugger' and 'src apps debugger', as that would supply a bit more detailed information about the crashes. Examples of how to do so can be found in build/jam/UserBuildConfig.readme.
by , 8 years ago
Attachment: | Debugger-1115-debug-11-12-2016-11-34-02.report added |
---|
hrev50755 with debug
comment:20 by , 8 years ago
I have the same crash as luroh when trying to save report from crashing media_addon_server. hrev50755 gcc2h
comment:24 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Resolving this one as fixed. The thread acquisitions added in hrev50753 should resolve the initially reported crash, as that perfectly fits what would've happened if a Web+ worker thread exited while we were in the middle of dumping more detailed thread information, especially if we had to wait for an async debug info request to complete, as the team lock is released during such waits.
I will also attach the Webpositive debug report and the syslog in the event they are somehow interrelated.