Debugger crash in Thread::IsMainThread

[vidrep]

hrev50701 x86_gcc2 Open YouTube video After a couple of minutes Webpositive crashed followed immediately by a Debugger crash. Debugger crash report attached

[vidrep]

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

[anevilyak]

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.

[bonefish]

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) ;-).

[anevilyak]

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?

[bonefish]

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

[vidrep]

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.

[vidrep]

Attached a debug report for crash on YouTube using hrev50749 x86_gcc2

[anevilyak]

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.

[vidrep]

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

[anevilyak]

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?

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

[anevilyak]

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.

[anevilyak]

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.

[vidrep]

Your commit references trac ticket 13802 instead of 13082.

[anevilyak]

Actually it winds up referencing both, a typo on my part at the end. Too late to fix that how in any case.

[vidrep]

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)

[anevilyak]

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.

[vidrep]

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

[luroh]

hrev50755 with debug

[KapiX]

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

[anevilyak]

Thanks luroh. Should be fixed in hrev50756.

[luroh]

Yes, seems fixed. Thanks.

[anevilyak]

(In #13109) Fixed in hrev50756.

[anevilyak]

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.