This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Cygwin64] dash segfault


On 10/03/2013 3:20 PM, Peter Rosin wrote:
On 2013-03-10 19:31, Peter Rosin wrote:
On 2013-03-10 13:03, Corinna Vinschen wrote:
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.
I got the below with gdb as error_start.

As to what cygwin1.dll I've got, this is the uname -a output:
CYGWIN_NT-6.1 PEDA-PC 1.7.18(0.263/5/3) 2013-03-07 13:54 x86_64 Cygwin

So I guess the one from install. However, I did untar the release/cygwin
one as well, but, I did use "tar xkf". I did it from 32-bit Cygwin with
a "find .... | xargs -n 1 tar xzf" invocation after mirroring the install
and release areas. I didn't really expect clashes...

I'm now going to install the dll from release/cygwin (for real) and retry.
Ok, here's a crash with the dll from release, still with home-built dash
w/o -O2.
BTW, gdb's "t a a bt" command is your friend (thread apply all: bt)

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]