Re: [Cygwin64] dash segfault

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar 10 12:45, Corinna Vinschen wrote:
> On Mar 10 11:18, Corinna Vinschen wrote:
> > On Mar 10 00:05, Peter Rosin wrote:
> > > On 2013-03-09 13:50, Corinna Vinschen wrote:
> > > > On Mar  8 23:13, Peter Rosin wrote:
> > > >> Hi!
> > > >>
> > > >> I doubt there is a shortage of obscure things to track down in the land
> > > >> of 64-bit, but while building a package using the stuff from install/release
> > > >> I noticed a segfault in dash when it ran a libtool script to generate a
> > > >> dll. Retrying got the dll built correctly.
> > > >>
> > > >> Fact is, I do see segfaults once in a while, but retrying has always helped
> > > >> so far, so I haven't pursued it.
> > > >>
> > > >> How do I set up a debugger to get more info than the below stackdump?
> > > > 
> > > > I added a 64 bit Cygwin GDB package to the install area a couple
> > > > of days ago.  I guess a debug version of dash (especially built w/o
> > > > optimization) won't hurt either.
> > > 
> > > Ok, I recompiled dash locally (.../configure CFLAGS=-g --prefix=/usr)
> > > and used CYGWIN='error_start=C:\...\bin\dumper.exe' and got myself a
> > > core file...
> > > 
> > > Not much appears to be going on though, suggestions are welcome...
> > 
> > Hmm. What about error_start=C:\...\gdb.exe?  Maybe that gives you a bit
> > more "life" information.
> 
> Btw., I just checked the RIP value in the stackdump output you sent.
> 
> Assuming you're using cygwin1.dll from the base package, this would be
> ptmalloc3.cc, line 792.  This in turn would point to a call of free() on
> something not a valid pointer.
> 
> Assuming you're using cygwin1.dll from the cygwin-1.7.18-2.tar.bz2
> package in the 64bit/release area, that would be malloc-private.h, line 88.
> 
> That would be a mutex_unlock call from within the ptmalloc3 code.
> 
> The missing stack is a pity, though, since that leaves us with no
> trace about the cicumstances.  If you reproduce the same with a 
> non-optimized debug version of dash, does the stackdump contain a
> stack backtrace?

And, another btw., you should definitely use the cygwin-1.7.18-2.tar.bz2
version.  It fixes a serious bug present in the base package's Cygwin
DLL.  FWIW, I'm trying to reproduce the problem for the last half hour
by repeating a libedit build over and over again, but I can't get it to
crash.  I'm now going to send the mail in the hope that the crash
occurs right after I hit the send button.

[...just seconds pass...]

Yay, I have a crash right *before* I hit the send button.  The threat
alone seem to have convinced dash that it's time to stop kidding around.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat