From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12739 invoked by alias); 25 Sep 2014 09:35:56 -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 12728 invoked by uid 89); 25 Sep 2014 09:35:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 25 Sep 2014 09:35:55 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8P9Zp2u018530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Sep 2014 05:35:51 -0400 Received: from localhost.localdomain (ovpn-112-17.ams2.redhat.com [10.36.112.17]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8P9Zndx019385; Thu, 25 Sep 2014 05:35:50 -0400 Message-ID: <5423E1F4.4060105@redhat.com> Date: Thu, 25 Sep 2014 09:35:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Marc Mezzarobba , gdb@sourceware.org Subject: Re: [help] Calling malloc() from a Python pretty-printer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00078.txt.bz2 On 23/09/14 09:10, Marc Mezzarobba wrote: > 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? Though not expressly forbidden it is highly discouraged to call (in GDB parlance, an "inferior function call") in a pretty-printer. The results are too unpredictable. The inferior call might generate a signal (which in GDB will cause an error and the inferior will be stopped at the signal emission phase), or hit a breakpoint (similar I think to the signal), or a whole host of things where the pretty printer looses control of the inferior. An inferior function call generates a temporary "dummy" frame to execute the call, and there are several specialized conditions and limitations to be aware of (some of which I detailed earlier.) > My understanding of the documentation was that it should work. It should, but see above. > 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? 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, or in your pretty-printer the equivalent: foo = gdb.parse_and_eval (malloc (1024)) Also a backtrace from the crashing GDB would be optimal if you can generate one. > (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? Generally if you need to store information about an inferior during pretty-printing, it is often preferable to just allocate that storage in python. So say you needed to store an array of integers during you call, instead of doing something like: foo = gdb.parse_and_eval (calloc (100, sizeof(int))) Just instead create a python list in the pretty printer: foo = [] Then add to the list in Python. You can make such lists last the duration of the pretty printing call, or global. Usual Python syntax applies. Cheers, Phil