Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jul 1999 11:39:27 -0700 (PDT)
From:      Kip Macy <kip@lyris.com>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        hackers@FreeBSD.ORG, stable@FreeBSD.ORG
Subject:   new  seg fault in thread code
Message-ID:  <Pine.SOL.4.05.9907141136580.21964-100000@luna>
In-Reply-To: <199907141806.OAA25906@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I just rebuilt libc_r and relinked my application. I am now crashing right
away as opposed to after several hours as I have been.

Program terminated with signal 11, Segmentation fault.
#0  0x82fa07c in _thread_kern_sched_state_unlock ()
(gdb) bt
#0  0x82fa07c in _thread_kern_sched_state_unlock ()
#1  0x82f9891 in _thread_kern_sched ()
#2  0x82f9d21 in _thread_kern_sched_state ()
#3  0x8307ee3 in nanosleep (time_to_sleep=0xbfbfd2d4, 
    time_remaining=0xbfbfd2cc)
    at /usr/src/lib/libc_r/uthread/uthread_nanosleep.c:72
#4  0x8307b9e in sleep (seconds=1)
    at /usr/src/lib/libc_r/../libc/gen/sleep.c:63
#5  0x8285598 in os_this_thread::sleep (seconds_=1) at thisthrd.cpp:712
#6  0x825bce5 in lyris_CodeBase_Table::open (this=0x85bcd00,
Exclusive=false)
    at cbtable3.cpp:588
#7  0x82342f0 in lyris_Table::open (this=0xbfbfd538, Exclusive=false)
    at table.cpp:1004
#8  0x8048f9f in lyris_Config::open (this=0xbfbfd4fc, Exclusive=false)
    at config.cpp:257
#9  0x8048221 in lyris_Config::lyris_Config (this=0xbfbfd4fc) at
config.cpp:52
#10 0x814be41 in lyris_CommandLine::RunCommandLine (this=0x85adc90, 
    InArguments=@0xbfbfd788) at lyrcline.cpp:682
#11 0x8160e83 in main (argc=4, argv=0xbfbfd808) at lyrmain.cpp:59








On Wed, 14 Jul 1999, Daniel Eischen wrote:

> > Can someone familiar with the new threads code tell me what is causing the
> > following segmentation fault. Thanks.
> > 
> >                                 -Kip 
> > 
> > 
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
> >     at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281
> > 1281
> > PTHREAD_PRIOQ_INSERT_HEAD(pthread);
> > (gdb) bt
> > #0  0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
> >     at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281
> > #1  0x82f9edd in pthread_mutex_lock (mutex=0x83c3ad4)
> >     at /usr/src/lib/libc_r/uthread/uthread_mutex.c:387
> 
> I take it you're running -stable without any mods to the threads
> library, right?
> 
> There are some bugs in libc_r in stable that have been fixed in
> -current.  I think the one that you've hit is an uninitialized
> TAILQ_HEAD in a statically declared mutex (in localtime).  It's
> probably about time for a MFC.  If someone wants to give me the
> go-ahead, I can do it...
> 
> In the mean time, you can grab libc_r/uthread/* from -current
> and rebuild libc_r under -stable.
> 
> Dan Eischen
> eischen@vigrid.com
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
> 
> 




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.4.05.9907141136580.21964-100000>