Opened 4 years ago

Closed 2 years ago

#12155 closed bug (fixed)

Debugger crash

Reported by: vidrep Owned by: anevilyak
Priority: normal Milestone: Unscheduled
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Attachments (1)

Debugger-3239-debug-14-06-2015-11-47-36.report (20.9 KB) - added by vidrep 4 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 4 years ago by anevilyak

Is this reproducible for you by any chance?

comment:2 Changed 4 years ago by vidrep

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

comment:3 Changed 4 years ago by vidrep

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

comment:4 Changed 4 years ago by anevilyak

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

comment:5 Changed 4 years ago by 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?

comment:6 Changed 4 years ago by vidrep

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

comment:7 Changed 4 years ago by 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.

comment:8 in reply to:  6 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by 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.

comment:10 Changed 4 years ago by 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).

comment:11 Changed 4 years ago by anevilyak

Blocked By: 10292 added

comment:12 Changed 4 years ago by vidrep

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

comment:13 Changed 4 years ago by 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.

comment:14 in reply to:  10 Changed 4 years ago by 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.

comment:15 Changed 4 years ago by 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?

comment:16 Changed 4 years ago by 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.

comment:17 Changed 4 years ago by anevilyak

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

comment:18 Changed 4 years ago by 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?

comment:19 Changed 4 years ago by 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.

comment:20 Changed 4 years ago by 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.

comment:21 Changed 4 years ago by anevilyak

Please see if hrev49563 helps.

comment:22 Changed 2 years ago by anevilyak

Is this issue still reproducible?

comment:23 Changed 2 years ago by vidrep

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

comment:24 Changed 2 years ago by anevilyak

Blocked By: 10292 removed

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.

comment:25 Changed 2 years ago by anevilyak

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.