From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7949 invoked by alias); 31 Oct 2006 07:27:20 -0000 Received: (qmail 7935 invoked by uid 22791); 31 Oct 2006 07:27:18 -0000 X-Spam-Check-By: sourceware.org Received: from mxout.hispeed.ch (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 31 Oct 2006 07:27:16 +0000 Received: from indel.ch (84-73-11-232.dclient.hispeed.ch [84.73.11.232]) by smtp.hispeed.ch (8.12.11.20060308/8.12.6/taifun-1.0) with SMTP id k9V7RCxe026903 for ; Tue, 31 Oct 2006 08:27:12 +0100 Received: from FABI.indel.ch [192.168.1.91] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Tue, 31 Oct 2006 08:27:10 +0100 Message-Id: <5.2.0.9.1.20061031082318.0186a020@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 31 Oct 2006 07:27:00 -0000 To: gdb@sourceware.org From: Fabian Cenedese Subject: Re: Memleaks? In-Reply-To: <1162240667.9408.28.camel@localhost.localdomain> References: <5.2.0.9.1.20061030165930.01856ec0@NT_SERVER> <5.2.0.9.1.20061030123115.0185cec0@NT_SERVER> <5.2.0.9.1.20061030123115.0185cec0@NT_SERVER> <5.2.0.9.1.20061030165930.01856ec0@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sourceware.org X-Return-Path: cenedese@indel.ch X-Virus-Status: Clean X-DCC-spamcheck-01.tornado.cablecom.ch-Metrics: smtp-04.tornado.cablecom.ch 1377; Body=1 Fuz1=1 Fuz2=1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00308.txt.bz2 At 12:37 30.10.2006 -0800, Michael Snyder wrote: >On Mon, 2006-10-30 at 17:01 +0100, Fabian Cenedese wrote: >> At 08:45 30.10.2006 -0500, Daniel Jacobowitz wrote: >> >On Mon, Oct 30, 2006 at 12:40:56PM +0100, Fabian Cenedese wrote: >> >> I admit that I used not a state-of-the-art gdb, but I don't think that >> >> this was changed recently. I'd be pleased if you can correct me. >> >> >> >> GNU gdb 6.2.50_2004-10-14-cvs >> > >> >This is two years old; I can't really speculate on what has changed >> >since then. It may be simple memory leaks, or it may be something more >> >complex. >> >> Actually 6.5 behaves the same as 6.2.5. The difference was not the >> version but the calling. When started with "gdb --readnow" every file >> read will leave some memory behind and use more and more. So it >> seems that the full symbols are not cleaned up as well as the partial >> symbols. > >It's not at all surprising that that would make a difference. >With --readnow, you're going to do an enormous amount of mallocing. I don't mind the memory being used. I mind the memory not being freed upon subsequently reading a new file. That's in my eyes the definition of a memleak. Can somebody test this on Linux to find out if it's gdb or maybe cygwin? bye Fabi