This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [Cygwin64] dash segfault
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