Opened 7 years ago

Closed 7 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)

Debugger-3124-debug-18-11-2016-16-27-51.report (19.3 KB ) - added by vidrep 7 years ago.
WebPositive-2023-debug-18-11-2016-16-27-39.report (24.7 KB ) - added by vidrep 7 years ago.
syslog (211.1 KB ) - added by vidrep 7 years ago.
Debugger-577-debug-08-12-2016-10-41-18.report (17.6 KB ) - added by vidrep 7 years ago.
WebPositive-520-debug-08-12-2016-10-41-11.report (1.0 KB ) - added by vidrep 7 years ago.
syslog.2 (463.7 KB ) - added by vidrep 7 years ago.
WebPositive-1230-debug-08-12-2016-11-06-14.report (40.9 KB ) - added by vidrep 7 years ago.
Debugger-1933-debug-11-12-2016-01-37-43.report (38.2 KB ) - added by vidrep 7 years ago.
WebPositive-1141-debug-11-12-2016-01-26-04.report (37.6 KB ) - added by vidrep 7 years ago.
WebPositive-1732-debug-11-12-2016-01-37-34.report (467 bytes ) - added by vidrep 7 years ago.
syslog.3 (38.7 KB ) - added by vidrep 7 years ago.
Debugger-1115-debug-11-12-2016-11-34-02.report (47.1 KB ) - added by luroh 7 years ago.
hrev50755 with debug

Download all attachments as: .zip

Change History (36)

comment:1 by vidrep, 7 years ago

I will also attach the Webpositive debug report and the syslog in the event they are somehow interrelated.

Last edited 7 years ago by vidrep (previous) (diff)

by vidrep, 7 years ago

Attachment: syslog added

comment:2 by diver, 7 years ago

Summary: Debugger crashDebugger crash in Thread::IsMainThread

comment:3 by anevilyak, 7 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.

in reply to:  3 ; comment:4 by bonefish, 7 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) ;-).

in reply to:  4 ; comment:5 by anevilyak, 7 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?

in reply to:  5 comment:6 by bonefish, 7 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 vidrep, 7 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.

Last edited 7 years ago by vidrep (previous) (diff)

by vidrep, 7 years ago

Attachment: syslog.2 added

comment:8 by vidrep, 7 years ago

Attached a debug report for crash on YouTube using hrev50749 x86_gcc2

comment:9 by anevilyak, 7 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.

Last edited 7 years ago by anevilyak (previous) (diff)

comment:10 by vidrep, 7 years ago

OK. From now on I'll only attach the debugger reports. Thanks.

comment:11 by anevilyak, 7 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?

comment:12 by pulkomandy, 7 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.

in reply to:  12 comment:13 by anevilyak, 7 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 anevilyak, 7 years ago

I believe I've found the causes of these and fixed them in hrev50753. Please let me know how things go. This may also resolve #12155, since it likely has the same underlying causes.

comment:15 by vidrep, 7 years ago

Your commit references trac ticket 13802 instead of 13082.

comment:16 by anevilyak, 7 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 vidrep, 7 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 (2 Web+, 1 Debugger)

Version 0, edited 7 years ago by vidrep (next)

by vidrep, 7 years ago

Attachment: syslog.3 added

comment:18 by anevilyak, 7 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.

comment:19 by vidrep, 7 years ago

No, these are prebuilt images downloaded from the Haiku website.

Last edited 7 years ago by vidrep (previous) (diff)

comment:20 by KapiX, 7 years ago

I have the same crash as luroh when trying to save report from crashing media_addon_server. hrev50755 gcc2h

comment:21 by anevilyak, 7 years ago

Thanks luroh. Should be fixed in hrev50756.

comment:22 by luroh, 7 years ago

Yes, seems fixed. Thanks.

comment:23 by anevilyak, 7 years ago

Blocking: 13109 added

(In #13109) Fixed in hrev50756.

comment:24 by anevilyak, 7 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.