From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12189 invoked by alias); 25 Sep 2014 12:04:51 -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 12178 invoked by uid 89); 25 Sep 2014 12:04:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,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; Thu, 25 Sep 2014 12:04:49 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XX7mu-0003Lz-BI for gdb@sourceware.org; Thu, 25 Sep 2014 14:04:44 +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 ; Thu, 25 Sep 2014 14:04:44 +0200 Received: from marc by 194.94.98.184 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Sep 2014 14:04:44 +0200 To: gdb@sourceware.org From: Marc Mezzarobba Subject: Re: [help] Calling malloc() from a Python pretty-printer Date: Thu, 25 Sep 2014 12:04:00 -0000 Message-ID: References: <5423E1F4.4060105@redhat.com> 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/msg00080.txt.bz2 Phil Muldoon wrote: > That is a bug. Your call stack is smashed now, and GDB is saying it > cannot find the next frame. This should never happen. I would be > curious to see what the result of: > > (gdb) call malloc (1024) > > are from your inferior, Thank you very much for your reply. Here is what I get in various situations (after removing the call to malloc from the pretty-printer): (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) call malloc (1024) $1 = (void *) 0x601010 (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) call malloc (1024) $2 = (void *) 0x601420 (gdb) up #1 0x00000000004004e8 in bar (x=tada) at foo.c:7 7 return bar(y); (gdb) call malloc (1024) $3 = (void *) 0x601830 > or in your pretty-printer the equivalent: > > foo = gdb.parse_and_eval (malloc (1024)) The return values of malloc() are exactly the same as above, but (like in my original example) gdb fails after printing #1 0x00000000004004e8 in bar (x=tada) at foo.c:7 7 return bar(y); > Also a backtrace from the crashing GDB would be optimal if you can > generate one. Here is what I managed to get. Note that this is not with foo.c but with a significantly more complicated inferior (involving a dlopened object that calls the Maple C API, with both Maple and the master program using an LD_PRELOADed libgmp...). Also, crashes apparently tend to occur when the inferior was itself executing memory management functions when it was interrupted. I'm also including a partial backtrace of the inferior in case this is relevant. GDB: #0 frame_unwind_pc (this_frame=0x170002) at /home/zumbi/gdb-7.7.1+dfsg/gdb/frame.c:761 #1 0x000000000065d48c in get_frame_address_in_block ( this_frame=this_frame@entry=0x2409e00) at /home/zumbi/gdb-7.7.1+dfsg/gdb/frame.c:2162 #2 0x000000000065d592 in get_frame_address_in_block_if_available ( this_frame=this_frame@entry=0x2409e00, pc=pc@entry=0x7fff3f753040) at /home/zumbi/gdb-7.7.1+dfsg/gdb/frame.c:2226 #3 0x000000000051b514 in get_frame_block (frame=0x2409e00, addr_in_block=addr_in_block@entry=0x0) at /home/zumbi/gdb-7.7.1+dfsg/gdb/blockframe.c:62 #4 0x0000000000607e6d in dwarf_expr_frame_base (baton=0x7fff3f7531c0, start=0x7fff3f7530f8, length=0x7fff3f753100) at /home/zumbi/gdb-7.7.1+dfsg/gdb/dwarf2loc.c:360 #5 0x00000000006027b9 in execute_stack_op (ctx=ctx@entry=0x1748db0, op_ptr=0x7fd7f749db02 "\"h", op_ptr@entry=0x7fd7f749daff "\221\340|\"h", op_end=op_end@entry=0x7fd7f749db02 "\"h") at /home/zumbi/gdb-7.7.1+dfsg/gdb/dwarf2expr.c:954 #6 0x0000000000603a24 in dwarf_expr_eval (ctx=ctx@entry=0x1748db0, addr=addr@entry=0x7fd7f749daff "\221\340|\"h", len=len@entry=3) at /home/zumbi/gdb-7.7.1+dfsg/gdb/dwarf2expr.c:364 #7 0x0000000000604994 in dwarf2_evaluate_loc_desc_full (type=0x24977f0, frame=0x2409e00, data=0x7fd7f749daff "\221\340|\"h", size=3, per_cu=0xfd3490, byte_offset=0) at /home/zumbi/gdb-7.7.1+dfsg/gdb/dwarf2loc.c:2251 #8 0x000000000053576a in default_read_var_value (var=0x24c29e0, frame=0x2409e00) at /home/zumbi/gdb-7.7.1+dfsg/gdb/findvar.c:439 #9 0x000000000058b264 in read_frame_arg (sym=sym@entry=0x24c29e0, frame=frame@entry=0x2409e00, argp=argp@entry=0x7fff3f753370, entryargp=entryargp@entry=0x7fff3f753390) at /home/zumbi/gdb-7.7.1+dfsg/gdb/stack.c:345 #10 0x000000000058bbfd in print_frame_args (func=, frame=frame@entry=0x2409e00, num=num@entry=-1, stream=0xf4a410) at /home/zumbi/gdb-7.7.1+dfsg/gdb/stack.c:672 #11 0x000000000058c59f in print_frame (frame=0x2409e00, print_level=, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/zumbi/gdb-7.7.1+dfsg/gdb/stack.c:1203 #12 0x000000000058ca8f in print_frame_info (frame=0x2409e00, print_level=1, print_what=SRC_AND_LOC, print_args=-1029483744, print_args@entry=1, set_current_sal=1) at /home/zumbi/gdb-7.7.1+dfsg/gdb/stack.c:855 #13 0x000000000058cc7f in print_stack_frame (frame=0x2409e00, print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/zumbi/gdb-7.7.1+dfsg/gdb/stack.c:170 #14 0x0000000000653acf in execute_command (p=, p@entry=0xdbc230 "up", from_tty=1) at /home/zumbi/gdb-7.7.1+dfsg/gdb/top.c:468 #15 0x000000000059c335 in command_handler (command=0xdbc230 "up") at /home/zumbi/gdb-7.7.1+dfsg/gdb/event-top.c:435 #16 0x000000000059c8f4 in command_line_handler (rl=) at /home/zumbi/gdb-7.7.1+dfsg/gdb/event-top.c:632 #17 0x0000003fca22d52e in rl_callback_read_char () from /lib/x86_64-linux-gnu/libreadline.so.6 #18 0x000000000059c399 in rl_callback_read_char_wrapper ( client_data=) at /home/zumbi/gdb-7.7.1+dfsg/gdb/event-top.c:164 #19 0x000000000059ae71 in process_event () at /home/zumbi/gdb-7.7.1+dfsg/gdb/event-loop.c:342 #20 0x000000000059b2b7 in gdb_do_one_event () at /home/zumbi/gdb-7.7.1+dfsg/gdb/event-loop.c:406 #21 0x000000000059b4de in start_event_loop () at /home/zumbi/gdb-7.7.1+dfsg/gdb/event-loop.c:431 #22 0x00000000005949d3 in captured_command_loop (data=data@entry=0x0) at /home/zumbi/gdb-7.7.1+dfsg/gdb/main.c:267 #23 0x0000000000592a8a in catch_errors ( func=func@entry=0x5949c0 , func_args=func_args@entry=0x0, errstring=errstring@entry=0x73fcf5 "", mask=mask@entry=RETURN_MASK_ALL) at /home/zumbi/gdb-7.7.1+dfsg/gdb/exceptions.c:524 #24 0x0000000000595896 in captured_main (data=data@entry=0x7fff3f7539f0) at /home/zumbi/gdb-7.7.1+dfsg/gdb/main.c:1067 #25 0x0000000000592a8a in catch_errors ( func=func@entry=0x594d70 , func_args=func_args@entry=0x7fff3f7539f0, errstring=errstring@entry=0x73fcf5 "", mask=mask@entry=RETURN_MASK_ALL) at /home/zumbi/gdb-7.7.1+dfsg/gdb/exceptions.c:524 #26 0x0000000000595d64 in gdb_main (args=args@entry=0x7fff3f7539f0) at /home/zumbi/gdb-7.7.1+dfsg/gdb/main.c:1076 #27 0x000000000045484e in main (argc=, argv=) at /home/zumbi/gdb-7.7.1+dfsg/gdb/gdb.c:34 Inferior (frame #7 is the first one that triggers the display hook in this case, and gdb crashes after displaying the opening parenthesis): #1 0x000000000050a487 in safeRealloc (ptr=0xa593a0, size=16) at general.c:429 #2 0x000000000050a50f in wrapSafeRealloc (ptr=0xa593a0, old_size=8, new_size=16) at general.c:444 #3 0x00007ffff7ed9544 in __gmpz_realloc () from /home/marc/opt/maple/17/bin.X86_64_LINUX/libgmp.so #4 0x00007ffff7ed6638 in __gmpz_mul_2exp () from /home/marc/opt/maple/17/bin.X86_64_LINUX/libgmp.so #5 0x0000003429039c4f in mpfr_get_z () from /usr/lib/x86_64-linux-gnu/libmpfr.so.4 #6 0x000000342901c0f5 in mpfr_pow () from /usr/lib/x86_64-linux-gnu/libmpfr.so.4 #7 0x000000000055e5fc in __tryFaithEvaluationOptimizedPow ( >> (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...) > > I am curious why you need to call malloc? This was just the first thing I tried in order to obtain a buffer for sprintf when I started experimenting with pretty-printers... Thanks again, -- Marc