Mail Archives: cygwin/2003/01/30/05:32:50
I seem to be very chatty on this subject - and very lonely as well :(
Anyways, getting a testcase together is proving to be quite the challenge,
so I decided to try 'n' build gdb in stead. Apparently, it doesn't quite
build OOTB: I get the following:
--
/bin/sh ../../gdb-20030128-1/gdb/../ylwrap ""
../../gdb-20030128-1/gdb/c-exp.y y.tab.c c-exp.tmp --
/bin: not found
Copyright: not found
1998,: not found
total used free shared buffers cached
Mem: 259972 131344 128628 0 0 0
-/+ buffers/cache: 131344 128628
Swap: 514332 136176 378156
This: not found
This: not found
you: not found
it: not found
the: not found
either: not found
/usr/src/gdb-20030128-1-build/gdb/../../gdb-20030128-1/gdb/c-exp.y: 11:
Syntax error: word unexpected
make[1]: *** [c-exp.tab.c] Error 1
--
Before I start figuring this out, I was wondering if someone (Chris?)
could provide me with a gdb executable with debug symbols. (Don't send it
right away - just tell me you have it and you're willing to send it if you
are (willing to ...))
Otherwise, if someone could inform me as to how to build gdb OOTB, that
would be nice too. For the moment, I just downloaded the source with
Setup, made a directory gdb-build and did a ../gdb-.../configure && make
which didn't quite work.
Any feedback would be greatly appreciated!
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 -