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

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
applies.

Cheers,

Phil