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 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.

Cheers,
Peter

GNU gdb (GDB) 7.5.50.20130305-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/dash.exe...done.
Attaching to program `/usr/bin/dash.exe', process 45916
[New Thread 45916.0xb298]
[New Thread 45916.0xa19c]
[New Thread 45916.0x9730]
[New Thread 45916.0xb060]
[New Thread 45916.0xa584]
[New Thread 45916.0xaeb4]
(gdb) thread
[Current thread is 6 (Thread 45916.0xaeb4)]
(gdb) bt
#0  0x0000000076eb0531 in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x0000000076f57ef8 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#2  0x0000000000000000 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 45916.0xb298)]
#0  0x0000000076eb59db in ntdll!RtlEqualUnicodeString ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x0000000076eb59db in ntdll!RtlEqualUnicodeString ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x0000000000000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 45916.0xa19c)]
#0  0x0000000076eb137a in ntdll!ZwReadFile ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x0000000076eb137a in ntdll!ZwReadFile ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b1a7a in ReadFile ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 45916.0x9730)]
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b10dc in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 45916.0xb060)]
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b10dc in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()
(gdb) thread 5
[Switching to thread 5 (Thread 45916.0xa584)]
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b10dc in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()
(gdb)


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