[help] Calling malloc() from a Python pretty-printer

Phil Muldoon pmuldoon@redhat.com
Thu Sep 25 09:35:00 GMT 2014

On 23/09/14 09:10, Marc Mezzarobba wrote:
> Dear gdb gurus,
> (This is a repost of a question that I sent to the gdb@gnu mailing list
> a few days ago. My apologies to people who read both lists!)
> Is it supposed to be okay to call an inferior's function, and
> specifically malloc(), from a Python pretty-printer?

Though not expressly forbidden it is highly discouraged to call (in
GDB parlance, an "inferior function call") in a pretty-printer.  The
results are too unpredictable.  The inferior call might generate a
signal (which in GDB will cause an error and the inferior will be
stopped at the signal emission phase), or hit a breakpoint (similar I
think to the signal), or a whole host of things where the pretty
printer looses control of the inferior.  An inferior function call
generates a temporary "dummy" frame to execute the call, and there are
several specialized conditions and limitations to be aware of (some of
which I detailed earlier.)

> My understanding of the documentation was that it should work.

It should, but see above.

> But when 
> my pretty-printer that calls malloc() is invoked while the selected
> stack frame is not the innermost one, gdb complains that it detected an
> internal problem or just crashes. What am I doing wrong? Is there a fine
> print I missed? Or is that a bug?

That is a bug.  Your call stack is smashed now, and GDB is saying it
cannot find the next frame.  This should never happen. I would be
curious to see what the result of:

(gdb) call malloc (1024)

are from your inferior, or in your pretty-printer the equivalent:

foo = gdb.parse_and_eval (malloc (1024))

Also a backtrace from the crashing GDB would be optimal if you can
generate one.

> (In case someone has a better approach to suggest, here is what I am
> trying to achieve. I am working with a library that provides a version
> of sprintf() for its custom data structures, and I would like to write a
> lightweight pretty-printer that reuses this sprintf(). Given my use
> cases, I don't think it is much of a problem if the pretty-printer needs
> to be disabled to debug some issues where the additional allocations are
> likely to interact with the actual problem. And if possible I would like
> to avoid writing a separate Python interface for the library...)

I am curious why you need to call malloc? Generally if you need to
store information about an inferior during pretty-printing, it is
often preferable to just allocate that storage in python.  So say you
needed to store an array of integers during you call, instead of doing
something like:

foo = gdb.parse_and_eval (calloc (100, sizeof(int)))

Just instead create a python list in the pretty printer:

foo = []

Then add to the list in Python.  You can make such lists last the
duration of the pretty printing call, or global.  Usual Python syntax



More information about the Gdb mailing list