Mysterious random crashes with latest snapshots

Igor Pechtchanski pechtcha@cs.nyu.edu
Thu Jun 30 14:58:00 GMT 2005


On Thu, 30 Jun 2005, Dave Korn wrote:

> ----Original Message----
> >From: Igor Pechtchanski
> >Sent: 30 June 2005 05:51
>
> > Hi,
> >
> > I've been experiencing intermittent crashes on my Windows XP laptop with
> > the past few DLL versions (from 1.5.16 to the latest snapshot).
>
>   I haven't noticed anything untoward myself.
>
> > These are extremely hard to reproduce,
>
>   Oh, just great :(
>
> > and happen seemingly at random,
>
>   Oh, even better!

Yeah, tell me about it.

> > with various
> > applications (most often bash, but I've seen it happen with xargs, man,
> > etc).  The only correlation I noticed was that these seem to happen while
> > spawning child processes, and they occur more often with higher memory
> > usage.  I've only noticed the crashes of Cygwin applications --
> > everything else seems to run smoothly.
> >
> > I know this isn't much of a bug report,
>
>   I should drop a hippo on you!

I'll take a hippo over these crashes any day.  Or are you saying this is
TITTTL fodder?

> > but the details of what I've tried
> > are below (warning: [ ...SNIP!...]
>
> > Here's part of the debugging session:
>
> >   1 thread 6140.0x398  0x610469d1 in fork ()
> >     at /netrel/src/cygwin-snapshot-20050624-1/winsup/cygwin/pinfo.h:178
>
> > [Switching to thread 1 (thread 6140.0x398)]#0  0x610469d1 in fork ()
> >     at /netrel/src/cygwin-snapshot-20050624-1/winsup/cygwin/pinfo.h:178
>
>   Oh, kewl!  Source-level debugging!
>
> > 178     /netrel/src/cygwin-snapshot-20050624-1/winsup/cygwin/pinfo.h: No
> >         such file or directory.
>
>   Oh, not so kewl!  No source!

Heh, of course -- this is a snapshot we're talking about.  It *should*
refer to the filenames in the builder's build tree.  I have a local CVS
copy -- the mapping isn't *that* convoluted...

> > BTW, for some reason addr2line only decodes the first address:

Any ideas on that?  Is this a bug in addr2line?  After all, gdb does find
the source info for the second stack entry as well.  It doesn't look like
it's coming from another DLL.  Also, any ideas why the gdb stack is
screwed up?

> > debugging them?  I could compile a debugging version of the cygwin DLL
>
>   Seems like that would be a good idea.
>
> > with extra information printed
>
>   Or even without; the first thing to do is get exactly where the crash is
> happening, then look at what's going on there - that's the only way you'll
> know what extra information might be relevant to print out.

In case you haven't noticed, I'm running a snapshot, which, IIUC, *is* a
debug build.  And that doesn't help much, as you can see.

On second thought, do you mean actually compiling with --enable-debugging?
Does this produce extra debug information, or is it just about better
traces and being able to run alongside other Cygwin versions?

> And get an unoptimised build of it, because then you don't have to worry
> about FPOs and inlining and stuff.

Ah, now that makes sense.  Though inline functions from headers will still
be inlined, IIUC, and this is what we're looking at here.

> Configure a clean build directory, then run
>
>   make CFLAGS='-g -O0' CPPFLAGS='-g -O0' CXXFLAGS='-g -O0' all 2>&1 | tee build.log

[OT rant: I prefer

   make CFLAGS='-g -O0' CPPFLAGS='-g -O0' CXXFLAGS='-g -O0' all >build.log 2>&1 &
   tail -f build.log

That way, if I decide I don't want to see the output anymore, I can just
Ctrl-C the tail process, and leave the make running -- not the case with
tee].

> to get the best possible debugging experience from the cygwin dll.  Oh, that
> only affects the winsup/cygwin build, though, the newlib stuff would still
> be built with -O2; if you want that debuggable as well, you'll need to add
> something like
>
> NEWLIB_CFLAGS='-g -O0 -DHAVE_OPENDIR -DHAVE_RENAME -DSIGNAL_PROVIDED -D_COMPILING_NEWLIB -DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin'
>
> although to be really certain I'd say after configuring look in
> $objdir/i686-pc-cygwin/newlib/Makefile for the existing value and modify
> that.

Hopefully it won't come to that.

>   FWIW, if we're in operator-> and pinfo.h and fork, it's generally
> somewhere in the vicinity of that old MapViewOfFileEx call we all know and
> love so well.....

Yeah.  If I could reproduce this under strace, I could hopefully get some
more info, but no luck so far.  I'll report back if I can reproduce this
with a debug version of the DLL, probably closer to the weekend.

Thanks for the feedback, Dave.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list