- If a thread was already in a stopped state, but we received
an update that indicated something more specific, it would be
ignored, i.e. changing
from simply being in a debugged state to specifying a debugger
call + message. We now check both state and reason before ignoring
the update. Fixes debug reports not receiving the debugger call
message properly when intercepting an actual crash as opposed to
an app running inside the debugger.
- CommandLineUserInterface is now a team listener. Consequently, when asked
to generate a debug report on startup without running the input loop,
it now waits for receipt of the debug report event to terminate.
- Style fixes.
- DebugReportGenerator is now its own BLooper that generates reports asynchronously
instead of in TeamDebugger's message loop.
- If a stack trace isn't yet available, DebugReportGenerator now waits for it to
be generated.
- Extended Team to add a listener event for report generation completing. DebugReportGenerator
now generates such an event when it has finished writing a report.
- When invoked, starts up the CLI such that it bypasses waiting for
input and instead save a crash report of the running team, then exits.
Mainly intended to be used by debug_server.
It has no use, since we don't know its value and the list of colors
might be longer (for example, for ARM currently B_MAX_CPU_COUNT is
only 1). The modula operator later on makes sure we keep within the
bounds of the kColors array anyway.
- The Tools menu now contains an option to save a debug report for the currently
debugged team. For now this report contains the following:
A list of all loaded images, their base address and their size.
A list of all threads active in their team, and their state.
* For each thread that is in a debug or exception state,
a stack trace, and a register dump at the top frame will also be emitted.
Feedback on report format + included details welcome.
For now, when the option is requested, the report is saved to the desktop
with an auto-generated name based on the target team and the current
date/time.
* The HEADERS_DEPENDENCY isn't needed
for GLU as Mesa is a dependency and requires
GLU to build
* I actually didn't break the build,
we were however using the Mesa GLU headers
with the external GLU lib which could be bad
* Check if offset is actually an error code and attempt to compensate
At the very least don't use it as an offset (would be bad).
* Write to the output string directly instead of copying a temp string.
* Add a ToDo to check if day of week should go after time for locale
* Replace hardcoded 64 in GetCurrentDate().
... with day of week tacked on at the beginning.
This fixes#9143 by better allowing the Locale Kit to
format the time. It was localized before but now also
uses localized time separators.
There might be still a bug with day of week though,
depending on if day of week should go before or after
the time in your locale (It is hard coded to before).
* GCC 4.7 is more picky than GCC 4.6, so have to make changes accordingly
* Changes include addressing issues with scoping, redeclaration, etc.
Thanks Rene and Ingo for your input on these changes
This is some defensive coding that assumes that the AddTeamMenu(),
RemoveTeamMenu(), AddSeperatorItem(), and RemoveSeperatorItem()
methods might fail and tries to compensate. Although it is unlikely
to be the case that these methods could fail I am trying to prevent
the bug that caused #9151 to happen.