This is the mail archive of the
mailing list for the Cygwin project.
pthreads "problem" Re: GDB always receives sigsegv with cygwin 1.3.13-2
On Wed, Oct 16, 2002 at 07:07:16PM -0400, Rolf Campbell wrote:
>Program received signal SIGSEGV, Segmentation fault.
>0x77e88207 in _libkernel32_a_iname ()
>Undefined command: "traceback". Try "help".
>#0 0x77e88207 in _libkernel32_a_iname ()
>#1 0x00412820 in cygwin_premain3 ()
>#2 0x61083a7d in _libkernel32_a_iname ()
>#3 0x61083ae6 in _libkernel32_a_iname ()
>#4 0x61083b30 in _libkernel32_a_iname ()
>#5 0x61082989 in _libkernel32_a_iname ()
>#6 0x610852c5 in _libkernel32_a_iname ()
>#7 0x61085409 in _libkernel32_a_iname ()
>#8 0x0040f520 in __register_frame_info_bases ()
>#9 0x0040f568 in __register_frame_info ()
>#10 0x0040105f in __do_frame_init ()
>#11 0x61005ed5 in _libkernel32_a_iname ()
>#12 0x61007a1b in _libkernel32_a_iname ()
>#13 0x004010da in main (numArgs=3, args=0xa010fc0) at S2Raw.cc:30
>#14 0x61007549 in _libkernel32_a_iname ()
>#15 0x6100780d in _libkernel32_a_iname ()
>#16 0x004123c2 in cygwin_crt0 ()
>#17 0x0040103c in mainCRTStartup ()
>#18 0x77e9ca90 in _libkernel32_a_iname ()
Ok. This is occurring in code compiled via gcc 3. gcc 3 uses a phreads
mutex which is assigned to PTHREAD_MUTEX_INITIALIZER. There is a check
for whether the mutex pointer is valid or not. It isn't valid as a
pointer but it is still a valid value. So, a "harmless" SIGSEGV occurs
while checking the pointer. The program traps the SIGSEGV so you never
see it but that is immaterial to gdb which dutifully reports it.
So, in the command line at least, you will be able to just continue on.
Robert Collins, can this behavior be changed? Can we avoid checking
PTHREAD_MUTEX_INITIALIZER for validity. I think you may have done this
once before, in fact.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html