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 <g...@sourceware.org>.
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/
