Mail Archives: cygwin/2003/01/30/09:41:11
For info: I files this as a problem report for gdb: PR gdb/976
Still working on getting more info (but also trying to debug the program
:)
rlc
On Wed, 29 Jan 2003, Ronald Landheer-Cieslak wrote:
> 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)
> >
> >
> >
>
--
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/
- Raw text -