1.5.6-pre: Occasional bad memory accesses within cygwin1.dll

Christopher Faylor cgf-no-personal-reply-please@cygwin.com
Wed Dec 31 01:30:00 GMT 2003


On Tue, Dec 30, 2003 at 03:45:18PM -0600, Brian Ford wrote:
>On Tue, 30 Dec 2003, Christopher Faylor wrote:
>
>> On Tue, Dec 30, 2003 at 02:36:12PM -0600, Brian Ford wrote:
>> >On Mon, 29 Dec 2003, Christopher Faylor wrote:
>> >
>> >> On Sun, Dec 28, 2003 at 03:52:33PM -0000, Max Bowsher wrote:
>> >> >I installed a self-built cygwin HEAD version - mostly it works fine, but it
>> >> >causes odd failures during builds (speculation: race when many processes
>> >> >being created and destroyed?)
>> >> >
>> >> >The most common failure is a Windows error box:
>> >> >
>> >> >The instruction at "0x6108621a" references memory at "0x610030b0". The
>> >> >memory could not be written.
>> >> >
>> >> >(These addresses are constant.)
>> >> >
>> >> >$ addr2line -e /bin/cygwin1.dll 0x6108621a 0x610030b0
>> >> >.../src/winsup/cygwin/shm.cc:331
>> >> >.../src/winsup/cygwin/cygthread.cc:34
>> >>
>> >> This isn't too useful, unfortunately.  The line numbers are an artifact
>> >> of the fact that there is no STABS information in the generated asm in
>> >> 'sigfe.s'.  Can you get an assembly listing of the lines around this
>> >> instruction?
>> >>
>> >I think this is the same problem.  It shows up all over the place for me
>> >in the testsuite.
>> >
>> >$ env
>> >GNU gdb 5.3
>> >Copyright 2002 Free Software Foundation, Inc.
>> >GDB is free software, covered by the GNU General Public License, and you are
>> >welcome to change it and/or distribute copies of it under certain conditions.
>> >Type "show copying" to see the conditions.
>> >There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> >This GDB was configured as "i686-pc-cygwin"...
>> >(gdb) r
>> >Starting program:
>> >/home/ford/downloads/cygb2/i686-pc-cygwin/winsup/testsuite/testsuite/checksignal.exe
>> >
>> >Program received signal SIGSEGV, Segmentation fault.
>> >0x6108bcad in _sigfe ()
>> >Current language:  auto; currently c++
>> >(gdb) bt
>> >#0  0x6108bcad in _sigfe ()
>> >#1  0xffffffff in ?? ()
>> >#2  0x00402b1f in cygwin_crt0 (f=0x401134 <main>)
>> >    at ../../../../cygwin/winsup/cygwin/lib/cygwin_crt0.c:24
>> >#3  0x0040103c in mainCRTStartup ()
>> >#4  0x77f1bb7b in _system_dlls__ ()
>> >(gdb) disassemble
>> >Dump of assembler code for function _sigfe:
>> >0x6108bc90 <_sigfe>:    push   %edx
>> >0x6108bc91 <_sigfe+1>:  mov    %fs:0x4,%eax
>> >0x6108bc97 <_sigfe+7>:  mov    $0x4,%edx
>> >0x6108bc9c <_sigfe+12>: xadd   %edx,0xffffeff8(%eax)
>> >0x6108bca3 <_sigfe+19>: lea    0x6108bcb1,%eax
>> >0x6108bca9 <_sigfe+25>: xchg   %eax,0x8(%esp,1)
>> >0x6108bcad <_sigfe+29>: mov    %eax,(%edx)
>> >0x6108bcaf <_sigfe+31>: pop    %edx
>> >0x6108bcb0 <_sigfe+32>: ret
>> >End of assembler dump.
>> >(gdb)
>>
>> $edx?
>>
>(gdb) p $edx
>$1 = 0

Oh.  This is probably with current CVS, which is broken.  Known problem.
It's why I haven't generated a snapshot yet.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list