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)
>
>
>
gdb.strace.gz
Description: GDB strace
cygcheck.out.gz
Description: Cygcheck output
-- 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/
