Memleaks?

Memleaks?

[Fabian Cenedese]

Hi

I was using gdb compiled with cygwin for Windows (XP). I noticed that
the memory usage was continuously increasing. So I made a test:
I just repeatedly loaded a symbol file without doing other stuff. Some
times I'd just do "file" to clear the symbols. I looked with Process Explorer
at the memory usage. It seems as this memory is never completely
freed until gdb quits. But sometimes restarting gdb isn't an option
so this memory increase is a bit disturbing.

Is this a known problem? Am I seeing something else? Is there some
kind of flush command (couldn't find) or should "file" release all allocated
memory?

http://img172.imageshack.us/img172/4447/gdbmemleakib1.gif

gdb without a symbol file would use about 3.5MB but that fell off the scale.

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
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi".

Thanks

bye  Fabi

Re: Memleaks?

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Memleaks?

[Fabian Cenedese]

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.

I tried a self-compiled gdb 6.5. This seems a lot better.

http://img163.imageshack.us/img163/2033/gdbnomemleakcy3.gif

GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi".

(gdb) file dragon.x
Load new symbol table from "/data/gdb-6.5/gdb/dragon.x"? (y or n) y
Reading symbols from /data/gdb-6.5/gdb/dragon.x...
unknown symbol type 0x1e...done.
(gdb) info symbol 0xbca60
CINOS1ms::AddTimer(long *) + 72 in section .text
(gdb) info address CINOS1ms::AddTimer(long *)
During symbol reading, struct/union type gets multiply defined: struct CINOSBusModule.
During symbol reading, forward-referenced types left unresolved, type code 0..
Symbol "AddTimer__8CINOS1msPl" is a function at address 0xbca18.

I'm just wondering about the warnings. Is this serious? The debug info
in the symbol file is stabs.

Thanks

bye   Fabi

Re: Memleaks?

[Daniel Jacobowitz]

On Mon, Oct 30, 2006 at 04:04:26PM +0100, Fabian Cenedese wrote:
> (gdb) info address CINOS1ms::AddTimer(long *)
> During symbol reading, struct/union type gets multiply defined: struct CINOSBusModule.
> During symbol reading, forward-referenced types left unresolved, type code 0..
> Symbol "AddTimer__8CINOS1msPl" is a function at address 0xbca18.
> 
> I'm just wondering about the warnings. Is this serious? The debug info
> in the symbol file is stabs.

I've no idea; probably not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Memleaks?

[Fabian Cenedese]

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.

bye  Fabi

Re: Memleaks?

[Michael Snyder]

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.

Re: Memleaks?

[Fabian Cenedese]

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

Re: Memleaks?

[Christopher Faylor]

On Mon, Oct 30, 2006 at 08:45:10AM -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.

FWIW, the current Cygwin version of gdb is 6.5+.

cgf

Re: *SPAM*Re: Memleaks?

[Fabian Cenedese]

At 07:16 31.10.2006 -0500, Christopher Faylor wrote:
>On Mon, Oct 30, 2006 at 08:45:10AM -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.
>
>FWIW, the current Cygwin version of gdb is 6.5+.

Which has the same errors.

bye  Fabi