Bug in gdb (memory leak?)

Ronald Landheer-Cieslak ronald@landheer.com
Tue Jan 28 17:54:00 GMT 2003


Hello all,

I've found a bug in gdb that I'm pretty sure is a memory leak (either that
or an infinite regression). Here's the general description of how I
produced it: 

I have a fairly small program that uses Xerces-C. When run normally (or
under Linux's gdb) there is no problem at all.  When run under Cygwin's
gdb, with just "run" and no fancy breakpoints, no problem either. However,
when I "next"  through the code (at least in -w mode - haven't gotten
around to trying in textmode yet) the program eats 100% CPU and
(eventually) 100% memory when I "next" over a Xerces-C setErrorHandler()
on a DOMImplementationLS parser.

Eventually, it eats all of my memory, the system complains of a lack of 
virtual memory and the program dies. Until that time, my system is pretty 
useless.

When it's done strace-ing, I'll attach the file (I'll go get a cup of
coffee first - I have a lot of memory to waste). In the mean time, I've
noticed that gdb does not have any debug information, so I can't do much
in the way of debugging this problem.

What I got from tailing the strace looks like a memory leak to me, but as 
I have no idea how gdb works internally, I can't make much of it...

I'll provide a small test case if I can get one to fail with the same
error. As Cygwin is only a debug platform for me, and the code I work on
is proprietary, I can't send you the code of the failing program itself :(

Other interesting facts: while doing "next" over the instruction makes the 
program misbehave, putting a breakpoint just behind it and "continue"-ing 
doesn't! (Kinda makes me wonder how "next" is implemented...)

Using the Windows taskmanager shows it really is gdb eating up all my
memory. The strace output file has eaten up all of my disk space before
gdb got around to eating up all of my memory, so I couldn't quite let it 
go to the end the first time around. The second time, my system no longer 
responded so I couldn't get any strace at all, do the third time, I 
decided to stop it after 10 minutes killing gdb from the task manager.

An earlier run produced a stackdump, which I jave attached as well.

Hope it helps. If you need more info, just ask.

Ronald Landheer-Cieslak (rlc)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace.out.gz
Type: application/x-gzip
Size: 6973 bytes
Desc: strace output
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030128/6d7329bf/attachment.bin>
-------------- next part --------------
1523564658 [sig] gdb 390 handle_exceptions: Exception: STATUS_STACK_OVERFLOW
Exception: STATUS_STACK_OVERFLOW at eip=610BCA03

eax=00001038 ebx=00000000 ecx=00CBBBB8 edx=610C4684 esi=00000000 edi=00010007

ebp=00CBFBB8 esp=00CBFBB0 program=C:\cygwin\bin\gdb.exe

cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023

Stack trace:

Frame     Function  Args

00CBFBB8  610BCA03  (61011D00, 00227568, 00000001, 00000000)

00CBFBD8  61011DE8  (00227568, 00000001, 00000001, 61013F2D)

00CBFF08  610141B3  (00000006, 00000001, 61074DED, 61074EE1)

00CBFF88  610754F1  (610C3628, 806B29E0, F16F2E20, 8096DBA4)

00CBFFB8  610053E8  (610C3628, 77DC0000, 0022FD8C, 610C3628)

00CBFFEC  77F04EDE  (61005340, 610C3628, 00000000, 000000B0)

End of stack trace
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


More information about the Cygwin mailing list