#12317: Debugger (silent?) crash, incomplete report
-------------------------------------+----------------------------
Reporter: ttcoder | Owner: anevilyak
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Applications/Debugger | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-------------------------------------+----------------------------
Comment (by anevilyak):
The overall system symptoms described here sound suspiciously similar to
ticket #10279, especially in light of this also being an AMD system as in
that ticket. That having been said, this report actually does not appear
to be truncated per se. The report generator operates in a strictly
sequential fashion, ergo if it had crashed while retrieving the stack
trace, the report would have stopped at the thread list, while this one
appears to have made it all the way to the end of listing all the
semaphores (the last step in report generation). The crash excerpt from
syslog as such appears to be unrelated to this particular report, but for
what it's worth appears to be heap corruption-related, as it's simply in
the process of retrieving the list of symbols for an image there. Without
further information there's not really much to be able to analyze there.
With regards to this report specifically: stack traces are only dumped for
any thread that is in the team and listed in some form of stopped state.
These include unrecoverable exception (the most typical reason for a
crash, this covers page fault, divide by zero, etc.), debug assertion (an
explicit `debugger()` call or `assert()` failure), or simply having been
manually debugged while running in the debugger itself. In this particular
report, none of the threads appear to be in such a state, hence the
absence of a backtrace. Since I'm unfamiliar with CommandCenter however,
I'm unable to say if a particular thread is missing in action, but since
you say _MediaRoster_ is expected to be there, it would be interesting to
know if syslog contains anything of interest with regards to CommandCenter
specifically (excerpts like the one posted in this ticket are printed for
the crashing team even before entering the debugger itself). I"m afraid
I'm at a loss as to why the thread would be gone entirely though, but I
don't really see how Debugger itself could be at fault, since the crash
state is trapped by the kernel before handing it off to the debug_server
to decide what to do with it (debug_server is the one responsible for
presenting the usual Terminate, Debug, Save Report dialog and taking the
requested action), so this may indicate an issue somewhere along the way
there.
Furthermore, it may also be worth enabling [http://cgit.haiku-
os.org/haiku/tree/data/settings/kernel/drivers/kernel#n27 syslog
timestamps] in order to be able to more accurately correlate syslog
information with the time at which a report was generated, since I'm
presuming that the customer isn't necessarily supplying you with this data
in real time.
--
Ticket URL: <https://dev.haiku-os.org/ticket/12317#comment:3>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
