From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5313 invoked by alias); 31 Oct 2002 06:05:27 -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 5126 invoked from network); 31 Oct 2002 06:05:25 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by sources.redhat.com with SMTP; 31 Oct 2002 06:05:25 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id IAA20854; Thu, 31 Oct 2002 08:05:09 +0200 (IST) Date: Wed, 30 Oct 2002 22:05:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: Fredrik Tolf cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: malloc() debugging In-Reply-To: <006e01c28051$58125d20$8400a8c0@dolda2000.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00221.txt.bz2 On Wed, 30 Oct 2002, Fredrik Tolf wrote: > Shouldn't gdb be enabled to do this in that case? You cannot do that in a general manner; see below. > Speaking of which, can't gdb create watchpoints to these structuress > every time malloc is called with conditions of $pc outside the malloc > functions and delete them when free is called? That might work (barring the problem with limited watchpoint resources), but the showstopper is that you need an intimate knowledge about the C library's implementation of malloc, and you need to make sure the program was linked against a version of the library where debug info wasn't stripped.