From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21303 invoked by alias); 25 Aug 2003 18:25:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21274 invoked from network); 25 Aug 2003 18:25:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 25 Aug 2003 18:25:38 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h7PIPcl18656 for ; Mon, 25 Aug 2003 14:25:38 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h7PIPbs31192; Mon, 25 Aug 2003 14:25:37 -0400 Received: from localhost.localdomain (vpn50-17.rdu.redhat.com [172.16.50.17]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h7PIPbHq002384; Mon, 25 Aug 2003 14:25:37 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h7PIPV509705; Mon, 25 Aug 2003 11:25:31 -0700 Date: Mon, 25 Aug 2003 18:25:00 -0000 From: Kevin Buettner Message-Id: <1030825182531.ZM9704@localhost.localdomain> In-Reply-To: Josef Wolf "Why malloc() when target code is executed?" (Aug 22, 10:48pm) References: <20030822204844.GC14466@raven.inka.de> To: Josef Wolf , gdb@sources.redhat.com Subject: Re: Why malloc() when target code is executed? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-08/txt/msg00281.txt.bz2 On Aug 22, 10:48pm, Josef Wolf wrote: > I just noticed that ``print printf("Hello\n")'' call malloc() on the target > to allocate the memory for the string. AFAICS, this memory never gets freed. > Is there any reason not to allocate this memory on the stack? This would > avoid this memory leak. In addition, this would make it possible to use this > feature on embedded systems which often have either restricted memory or > even dont have malloc() at all. For printf(), allocating the string on the stack is (usually) okay. This is because printf() doesn't return a pointer to the string nor does it write the string pointer to some data structure in the inferior process. Functions which did either of these could/would end up with a dangling pointer if the string were to be allocated on the stack. OTOH, using malloc() (and never freeing the allocated space) ensures gdb won't be responsible for the debugged program having a dangling pointer reference. I agree that it is not desirable for gdb to introduce a memory leak in the debugged process, but it's even worse for gdb to introduce dangling pointer references. It might be tempting to special case printf() and perhaps several other well behaved functions so parameter storage is allocated on the stack instead of being malloc'd. However, there is nothing preventing the debugged process from overriding the usual well behaved function definitions with less well behaved ones. So, if this code for special casing a handful of well behaved functions were added to GDB, there'd need to be a user settable mode indicating such. The default for such a mode should be GDB's current behavior. Kevin