Calling malloc() from a Python pretty-printer

[Marc Mezzarobba]

Dear gdb gurus,

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