Debugger crash

[vidrep]

​​http://www.calgarysun.com/ Reading articles on the above website triggered a simultaneous debug report for Webpositive and debugger. hrev49292 x86_64 debugger debug report attached

[anevilyak]

Is this reproducible for you by any chance?

[vidrep]

I tried to trigger the debug report in the same manner as before to no avail. Plenty of Web+ crashes though...

[vidrep]

anevilyak, Is there a user guide or tutorial located somewhere for debugger functions?

[anevilyak]

I've been working on one, but it's not quite ready yet at this point.

[vidrep]

Had it happen again today while trying to attach a screenshot to a new ticket. First Webpositive crashed, causing the debugger to activate. After saving the debug report the debugger would not close, causing a system lockup. I had to kill debugger from team monitor. Next time, what steps could I take to obtain useful information?

[vidrep]

The ticket For the Web+ crash was #12215. Maybe there is something useful is in the attached report.

[anevilyak]

Offhand, the main thing that could potentially be useful is (if possible) dropping into KDL via alt+printscreen+d and getting stack traces of each of the debugger's threads. This can be done by first using the teams command to ask for the list of teams, then threads team_id for the id corresponding to the Debugger team, and then for each thread ID in the resulting list, bt id. Continuing out of KDL afterwards via continue should then eventually result in all of those backtraces getting written to syslog, which you could then either attach or copy/paste from.

[anevilyak]

Replying to vidrep:

The ticket For the Web+ crash was #12215. Maybe there is something useful is in the attached report.

Unfortunately not. The report itself actually looks complete, which only makes things more puzzling, since that eliminates most of the obvious possible reasons it might be hanging.

[vidrep]

Right now, Haiku is about as unstable as it has ever been since I first started using it. Almost everything that I normally use on Haiku is either broken or crash prone, thus making it virtually useless to me, even for testing purposes. I'm trying to do my part to help make Haiku better, but the frustration level is growing with each new broken app or function.

[anevilyak]

I'm sorry to hear that, though I'm afraid I can't say I've personally seen similar instability, though that may be a result of us using different apps.

As far this particular ticket is concerned though, a thought occurred to me this morning as to where the problem might lie, so I was wondering if you'd be willing to try an experiment for me, as I've been completely unable to reproduce this particular problem: For the time being, when a crash occurs, rather than picking Save Report directly from the crash dialog, can you enter the debugger via Debug and then save the report from the Tools menu? If this consistently works (and you're subsequently able to close the debugger without something hanging), that would point to the possibility that something's wrong in the CLI front end somewhere (when invoked to save a crash report directly, the CLI is started rather than the GUI).

[vidrep]

Next time I'll try your suggestion - whatever I can do to help resolve this issue.

[vidrep]

I was able to reproduce this problem several times last night by opening a "new issue" on GitHub, and then attempting to upload a screenshot to attach to the ticket. First Web+ crashes, a dialog appears for creating a debug report, then both Web+ and debugger have to be killed in team monitor. Tonight I'll try again using your previous suggestion, as it didn't occur to me to try it last night.

[vidrep]

Replying to anevilyak:

As far this particular ticket is concerned though, a thought occurred to me this morning as to where the problem might lie, so I was wondering if you'd be willing to try an experiment for me, as I've been completely unable to reproduce this particular problem: For the time being, when a crash occurs, rather than picking Save Report directly from the crash dialog, can you enter the debugger via Debug and then save the report from the Tools menu? If this consistently works (and you're subsequently able to close the debugger without something hanging), that would point to the possibility that something's wrong in the CLI front end somewhere (when invoked to save a crash report directly, the CLI is started rather than the GUI).

I tried as you suggested and the debugger did not hang, but closed down cleanly. This issue can be consistently reproduced by trying to attach a screenshot to a GitHub ticket.

[anevilyak]

Thanks for the hint, I'll hopefully be able to find time to try that sometime this weekend. For reference, does it matter what architecture you try it on? I.e. did it only occur on x86_64?

[vidrep]

Currently, I'm only testing the "official" x86 gcc2 build. I haven't used 64 bit for a while now. I could check to see if it also happens there.

[anevilyak]

No need, I just wanted to ensure that I knew what to test with, since the initial report was for -64.

[anevilyak]

Just tried on hrev49560 over here, and while the aforementioned steps do indeed crash Web+ quite reliably, I'm still not able to reproduce a debugger hang. I should note though, that the first time it happens, it takes around 30-45 seconds on my i7 to finish generating the report and exit, during which time it's busy in the main thread if you drill down to its thread list in ProcessController. Is this also the case for you, or does it appear completely idle?

[vidrep]

I'll give it a try tonight after work. Should I wait a full minute after generating a debug report to see if the debugger closes on its own? Ideally, Web+ will eventually get fixed, then we won't need to generate debug reports at all.

[anevilyak]

The main question of interest for me right now is if the debugger is actually busy doing something, or if it's simply asleep/idle, so it would be nice to know its CPU usage in ProcessController looks like. The behavior over here is that, when running through the steps immediately at boot, web+ crashes -> save report -> debugger's busy for 30-45 seconds -> both of them exit. Repeating the test drops that time down to more like 5-10 seconds, most likely due to disk caching. In both cases the Web+ window goes away at the same time as the debugger though, so if that's not the same as your experience then the question is why.

Assuming it appears idle, you could try to open another debugger instance from Deskbar, attach to the one generating the report, interrupt all its threads (except for the debug task thread), and save a report then, if you're able to do so. That'd at least yield some information as to what state it's in at this point. That having been said, I'm also going to work on some changes to revamp how things are executed in the case of launching the debugger solely for the purpose of creating a report, which might resolve the issue in a different way, but that will take some time, so in the interim, trying to understand this issue would be helpful either way.

[anevilyak]

Please see if hrev49563 helps.

[anevilyak]

Is this issue still reproducible?

[vidrep]

I have not seen this issue for a long time. It's probably safe to close.

[anevilyak]

Thanks for the update! Please let me know if you run into anything similar again.

• Unlinking #10292 since report saving via the crash dialog is no longer handled via CommandLineUserInterface, so that issue is separate entirely.