Re: [ros-kernel] More useful stack traces

[Casper H. <ch...@us...>]

s=F8n, 2002-07-14 kl. 18:26 skrev David Welch:
> On Sun, Jul 14, 2002 at 02:52:55PM +0200, Casper Hornstrup wrote:
> > Also, core dumping is only useful to developers when they have symbol
> > information. This would mean that either 1) the core dump would contain
> > the symbols (meaning that non-stripped images need to be used or the
> > symbols come from the .sym files) or b) core dumps are limited to beein=
g
> > generated by official releases so the developer has the symbol
> > information available. If b) then 6 months is probably too long between
> > releases.=20
> >
> The way I envisaged it working was that the user would run a tool to
> postprocess the core dump and produce information which could be emailed =
to us.
> We wouldn't want people sending 256MB files (or whatever the average memo=
ry
> size is these days) anyway. Obviously the core dump would have to contain
> a module list but the actual matching up of addresses to symbols could be
> done offline. Also we would need to have debugging information produced
> on builds of all types and included in offical releases. I don't see this
> as a big problem, ntoskrnl and the default hal have been built with '-g'
> unconditionally for years.

So you say it should dump the whole memory instead of just part of it (a
small memory dump in NT)? I guess it would not be too difficult to skip
free pages when dumping. Since you want to do post-processing, it sounds
like you don't care if the core dump can be interpreted by already
available debuggers like gdb. So, should we write our own tools to
interpret the core dumps or modify existing?

Let's talk about what information we need from a core dump in order to
fix a bug. The bugreport with the coredump should contain enough
information to reproduce the crash. There is of course the state of the
CPU registers at the time of the crash. Then there is the module list
and the process list.

In any case core dumps are usually not enough to reproduce a bug. The
following article provides guidelines on how to produce meaningful
bugreports:

http://freshmeat.net/articles/view/149/

Casper