Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 30 Jun 2005 10:18:26 -0400 (EDT) From: Igor Pechtchanski Reply-To: cygwin AT cygwin DOT com To: Dave Korn cc: cygwin AT cygwin DOT com Subject: RE: Mysterious random crashes with latest snapshots In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 AT cs DOT nyu DOT edu ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT 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/