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

[Sergio Durigan Junior]

On Saturday, September 20 2014, Marc Mezzarobba wrote:

> Dear gdb gurus,

Hello Marc,

Right now I don't have enough time to look at your message, but
nevertheless I'd like to say that this mailing is not really used by us
(GDB developers).  Instead, send your questions to <address@hidden>.

Thanks a lot!

> Is it supposed to be okay to call an inferior's function, and 
> specifically malloc(), from a Python pretty-printer?
>
> My understanding of the documentation was that it should work. 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?
>
> Here is a complete example:
>
>
> ==> foo.c <==
> struct foo { int val; };
>
> int bar(struct foo x) {
>     struct foo y = x;
>     --y.val;
>     if (!y.val) return 0;
>     return bar(y);
> }
>
> int main(void) {
>     struct foo x = { .val = 42 };
>     return bar(x);
> }
>
> ==> foo-gdb.py <==
> class Printer(object):
>     def __init__(self):
>         pass
>     def to_string(self):
>         gdb.lookup_symbol("malloc")[0].value()(256)
>         return "tada"
>
> def lookup_type(val):
>     return Printer()
>
> gdb.printing.register_pretty_printer(gdb, lookup_type)
>
> ==> transcript <==
> ~/docs/vrac/pygdb$ gdb foo
> GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
> [...]
> Reading symbols from foo...done.
> (gdb) break bar
> Breakpoint 1 at 0x4004c1: file foo.c, line 4.
> (gdb) r
> Starting program: /home/marc/docs/vrac/pygdb/foo 
>
> Breakpoint 1, bar (x=tada) at foo.c:4
> 4           struct foo y = x;
> (gdb) c 10
> Will ignore next 9 crossings of breakpoint 1.  Continuing.
>
> Breakpoint 1, bar (x=tada) at foo.c:4
> 4           struct foo y = x;
> (gdb) up
> #1  0x00000000004004e8 in bar (x=tada) at foo.c:7
> 7           return bar(y);
> /home/zumbi/gdb-7.7.1+dfsg/gdb/frame.c:2139: internal-error: 
> get_frame_pc_if_available: Assertion `frame->next != NULL' failed.            
>  
> A problem internal to GDB has been detected,                          
> further debugging may prove unreliable.                               
> Quit this debugging session? (y or n) y
>
> /home/zumbi/gdb-7.7.1+dfsg/gdb/frame.c:2139: internal-error: 
> get_frame_pc_if_available: Assertion `frame->next != NULL' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
>
>
> (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...)
>
> Can someone help me?
>
>
> Thanks a lot,
>
> -- 
> Marc Mezzarobba

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/