Bug in gdb (memory leak?)

[Ronald Landheer-Cieslak]

Just a follow-up on my own mail (more info) The same problem occurs when I
"next" over another Xerces-C DOMImplementationLS method -
DOMImplementationLS::parse().
I've attached strace to the process as soon as I could, but I couldn't get 
there before it relinquished some of my CPU.

Note, though, that I updated the installation this morning, and the new
gdb is part of the package.

`cygcheck -s -r -v` attached, as is gdb.strace
gdb didn't produce a stackdump when it croaked...

Hope it helps,

rlc

NB: I am more than willing to try this out on snapshots and the like - I 
    am running an snapshot of a few days ago (on which I tried the file 
    permissions) as is.
I'll try to set up a test case ASAP.

On Tue, 28 Jan 2003, Ronald Landheer-Cieslak wrote:
> 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: gdb.strace.gz
Type: application/x-gzip
Size: 1689 bytes
Desc: GDB strace
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030129/51211653/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck.out.gz
Type: application/x-gzip
Size: 4933 bytes
Desc: Cygcheck output
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030129/51211653/attachment-0001.bin>
-------------- 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/