Opened 13 years ago
Closed 12 years ago
#8088 closed bug (fixed)
Implement support for saving crash reports
Reported by: | anevilyak | Owned by: | anevilyak |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta1 |
Component: | Applications/Debugger | Version: | R1/Development |
Keywords: | Cc: | bonefish | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
In order for the Debugger to replace gdb, it needs the ability to save problem reports for crashed apps. These should at the very least include stack traces for all running threads, as well as possibly the register states if available, and also possibly the list of loaded libraries.
Change History (6)
comment:1 by , 12 years ago
Status: | new → in-progress |
---|
comment:2 by , 12 years ago
Cc: | added |
---|
comment:3 by , 12 years ago
If you can hold the horses for a bit longer, I'd first like to add a bit more stuff to the CLI. Since what is put into the crash report will possibly be very similar to what the stack trace command and others print, I think it makes sense to finish those first and then see how to best use or refactor the functionality for the crash report. I actually intended to look into that afterward myself, but if you want you can do that, of course.
comment:4 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | in-progress → assigned |
That's fine by me, I have plenty of other tickets to work on :)
comment:5 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | assigned → in-progress |
comment:6 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
While there are still some details remaining to be fleshed out in the case where no debug information is available, this feature is now implemented.
I'm a bit torn on the best way to proceed for this one. What I originally had in mind was as follows:
On the debugger side however, start_team_debugger() currently requires a user interface object to be passed to it. Since in this instance I don't ever want to present the user with a UI, there seem to be two possible ways to go here. Either 1) create a third UserInterface derivative which simply no-ops the various UI calls, and implements Show() to retrieve the appropriate information, write it to disk, and terminate, or 2) Add the functionality in question to the command line interface together with a flag telling it to not enter its UI loop but rather call the crash report functionality instead. Any preference, or perhaps a different approach entirely?