Re: Memleaks?

Fabian Cenedese
2006-10-30T15:06:17Z

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