debugging coredumps with the help of libraries (for example to pretty-print)

debugging coredumps with the help of libraries (for example to pretty-print)

[Simon Sobisch]

I currently think there is no way, but before "giving up" I've wanted to 
double-check, maybe I've missed something.

To pretty-print some data types it seems quite feasible to use whatever 
library handles the typedefs normally and use its string functions to 
get the developer-view of the data and let gdb output that.
And this actually works quite well, just `gdb.execute("call 
libfunc(...)") and you're done.

But when I now create a core-dump (gcore dumpfile) and then start gdb 
with to debug that I see the full state and local variables - but none 
of those pretty printers work, resulting in "You can't do that without a 
process to debug." messages.

Is it possible to let GDB itself load the libraries and pass resolve the 
string values that way (or somehow start a "new" process along with the 
coredump only for letting it print the values from the coredump data)?

If not then it is either "disable the pretty printing when a coredump is 
processed" [what is the best check for that in a python extension btw?] 
or try to re-implement the string function completely in python.

Note: I actually can also change the library in question if that helps, 
but I'd (also) be interested to know the answer of this question in general.

Any hints welcome,
Simon Sobisch

Re: debugging coredumps with the help of libraries (for example to pretty-print)

[David Blaikie]

Not sure about other answers/details, but generally it's encouraged to
do the latter - pretty printers that do not invoke any code in the
process, both for debugging cores, but also in general to avoid any
risk that the pretty printer might taint the process under test by
executing code that could risk changing the state of the process, etc.

On Thu, May 6, 2021 at 1:48 PM Simon Sobisch via Gdb <gdb@sourceware.org> wrote:
>
> I currently think there is no way, but before "giving up" I've wanted to
> double-check, maybe I've missed something.
>
> To pretty-print some data types it seems quite feasible to use whatever
> library handles the typedefs normally and use its string functions to
> get the developer-view of the data and let gdb output that.
> And this actually works quite well, just `gdb.execute("call
> libfunc(...)") and you're done.
>
> But when I now create a core-dump (gcore dumpfile) and then start gdb
> with to debug that I see the full state and local variables - but none
> of those pretty printers work, resulting in "You can't do that without a
> process to debug." messages.
>
> Is it possible to let GDB itself load the libraries and pass resolve the
> string values that way (or somehow start a "new" process along with the
> coredump only for letting it print the values from the coredump data)?
>
> If not then it is either "disable the pretty printing when a coredump is
> processed" [what is the best check for that in a python extension btw?]
> or try to re-implement the string function completely in python.
>
> Note: I actually can also change the library in question if that helps,
> but I'd (also) be interested to know the answer of this question in general.
>
> Any hints welcome,
> Simon Sobisch

Re: debugging coredumps with the help of libraries (for example to pretty-print)

[Tom Tromey]

>>>>> "Simon" == Simon Sobisch via Gdb <gdb@sourceware.org> writes:

Simon> But when I now create a core-dump (gcore dumpfile) and then start gdb
Simon> with to debug that I see the full state and local variables - but none 
Simon> of those pretty printers work, resulting in "You can't do that without
Simon> a process to debug." messages.

These are also somewhat dangerous to use.  I think there have been
reports of gdb crashes when calling inferior functions from
pretty-printers.  So, normally I recommend against doing this kind of
thing; though if it works for you, great.

It's possible some code in the Python layer isn't careful about using
frame-ids instead of frames.  That would cause bugs.  Also inferior
calls can cause other threads to run, which can be super confusing.

Simon> Is it possible to let GDB itself load the libraries and pass resolve
Simon> the string values that way (or somehow start a "new" process along
Simon> with the coredump only for letting it print the values from the
Simon> coredump data)?

There was a old wish list item to resurrect a core file and turn it into
a running process.  Maybe this is possible, maybe not.  As far as I
know, nobody has ever really tried.  Anyway, it doesn't exist, so the
current answer is 'no'.

Simon> If not then it is either "disable the pretty printing when a coredump
Simon> is processed" [what is the best check for that in a python extension
Simon> btw?] or try to re-implement the string function completely in python.

I would normally just reimplement it in Python.

Tom