From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22714 invoked by alias); 23 Sep 2014 08:15:10 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 22702 invoked by uid 89); 23 Sep 2014 08:15:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_WEB,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,T_FSL_HELO_BARE_IP_2 autolearn=ham version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 23 Sep 2014 08:15:07 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XWLFY-0001Nx-39 for gdb@sourceware.org; Tue, 23 Sep 2014 10:15:04 +0200 Received: from 194.94.98.184 ([194.94.98.184]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Sep 2014 10:15:04 +0200 Received: from marc by 194.94.98.184 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Sep 2014 10:15:04 +0200 To: gdb@sourceware.org From: Marc Mezzarobba Subject: [help] Calling malloc() from a Python pretty-printer Date: Tue, 23 Sep 2014 08:15:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit User-Agent: KNode/4.14 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00077.txt.bz2 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