[Cygwin64] dash segfault

[Ryan Johnson]

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