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

Marc Mezzarobba <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
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?

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.