Re: seg fault in mutex_queue_enq
Daniel Eischen eisc...@vigrid.com writes: Just tell me what to do, and I'll do it :-) I won't go that far, but I'd suggest keeping the versions in -current and -stable in sync (after testing new stuff in -current, of course). There's (yet) no technical reason not to do so and it makes maintenance much easier. tg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Thomas Gellekum [EMAIL PROTECTED] wrote: Daniel Eischen [EMAIL PROTECTED] writes: 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... Just Do It (tm). At least you could merge the change from [pthread_private.h] 1.20 Sun Jun 20 8:28:08 1999 UTC by jb Diffs to 1.19 In the words of the author: o The polling mechanism for I/O readiness was changed from select() to poll(). In additon, a wrapped version of poll() is now provided. [...] plus the later formatting fixes. The libc_r version number was bumped in -current because of the addition of poll(). Is this allowed in -stable, or something that waits for a -RELEASE? As an aside: some files still lack $Id$'s, and someone should `s/REGENTS/AUTHOR/' in all the copyright statements. OK. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seg fault in mutex_queue_enq
Daniel Eischen [EMAIL PROTECTED] writes: The libc_r version number was bumped in -current because of the addition of poll(). Is this allowed in -stable, or something that waits for a -RELEASE? Jordan should have to say something about this. AFAIR, bumps are allowed but only by one between releases. We will have to provide libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this anyway by the time 4.x is released). tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seg fault in mutex_queue_enq
On Thu, 15 Jul 1999, Jordan K. Hubbard wrote: :- Jordan should have to say something about this. AFAIR, bumps are :- allowed but only by one between releases. We will have to provide :- libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this :- anyway by the time 4.x is released). :- :-I'd prefer not to bump it... John Birrell and I are already not :-entirely in agreement that the change required a version bump at :-all. It didn't change any interfaces. Which failure is better: An error that you don't have a recent enough version of the library, or one that the routine poll() can't be found at run time? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seg fault in mutex_queue_enq
Jordan should have to say something about this. AFAIR, bumps are allowed but only by one between releases. We will have to provide libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this anyway by the time 4.x is released). I'd prefer not to bump it... John Birrell and I are already not entirely in agreement that the change required a version bump at all. It didn't change any interfaces. I don't care one way or the other. I could leave out the wrapped poll() very easily and avoid the issue all together. This would provide -stable with everything -current has, except of course poll(). I'd prefer to add poll, though... If you don't bump the version in -stable, then you could end up with two versions of libc_r that are not different (assuming -current doesn't make any subsequent changes that warrant a version bump). Just tell me what to do, and I'll do it :-) Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seg fault in mutex_queue_enq
Daniel Eischen eisc...@vigrid.com writes: 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... Just Do It (tm). At least you could merge the change from [pthread_private.h] 1.20 Sun Jun 20 8:28:08 1999 UTC by jb Diffs to 1.19 In the words of the author: o The polling mechanism for I/O readiness was changed from select() to poll(). In additon, a wrapped version of poll() is now provided. [...] plus the later formatting fixes. As an aside: some files still lack $Id$'s, and someone should `s/REGENTS/AUTHOR/' in all the copyright statements. tg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Thomas Gellekum t...@ihf.rwth-aachen.de wrote: Daniel Eischen eisc...@vigrid.com writes: 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... Just Do It (tm). At least you could merge the change from [pthread_private.h] 1.20 Sun Jun 20 8:28:08 1999 UTC by jb Diffs to 1.19 In the words of the author: o The polling mechanism for I/O readiness was changed from select() to poll(). In additon, a wrapped version of poll() is now provided. [...] plus the later formatting fixes. The libc_r version number was bumped in -current because of the addition of poll(). Is this allowed in -stable, or something that waits for a -RELEASE? As an aside: some files still lack $Id$'s, and someone should `s/REGENTS/AUTHOR/' in all the copyright statements. OK. Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Daniel Eischen eisc...@vigrid.com writes: The libc_r version number was bumped in -current because of the addition of poll(). Is this allowed in -stable, or something that waits for a -RELEASE? Jordan should have to say something about this. AFAIR, bumps are allowed but only by one between releases. We will have to provide libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this anyway by the time 4.x is released). tg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Thomas Gellekum t...@ihf.rwth-aachen.de writes: libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this /usr/src/lib/compat/compat3x Sorry. tg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Jordan should have to say something about this. AFAIR, bumps are allowed but only by one between releases. We will have to provide libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this anyway by the time 4.x is released). I'd prefer not to bump it... John Birrell and I are already not entirely in agreement that the change required a version bump at all. It didn't change any interfaces. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
On Thu, 15 Jul 1999, Jordan K. Hubbard wrote: :- Jordan should have to say something about this. AFAIR, bumps are :- allowed but only by one between releases. We will have to provide :- libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this :- anyway by the time 4.x is released). :- :-I'd prefer not to bump it... John Birrell and I are already not :-entirely in agreement that the change required a version bump at :-all. It didn't change any interfaces. Which failure is better: An error that you don't have a recent enough version of the library, or one that the routine poll() can't be found at run time? mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Jordan should have to say something about this. AFAIR, bumps are allowed but only by one between releases. We will have to provide libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this anyway by the time 4.x is released). I'd prefer not to bump it... John Birrell and I are already not entirely in agreement that the change required a version bump at all. It didn't change any interfaces. I don't care one way or the other. I could leave out the wrapped poll() very easily and avoid the issue all together. This would provide -stable with everything -current has, except of course poll(). I'd prefer to add poll, though... If you don't bump the version in -stable, then you could end up with two versions of libc_r that are not different (assuming -current doesn't make any subsequent changes that warrant a version bump). Just tell me what to do, and I'll do it :-) Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
I don't care one way or the other. I could leave out the wrapped poll() very easily and avoid the issue all together. This would provide -stable with everything -current has, except of course poll(). I'd prefer to add poll, though... I'm OK with adding poll(), it just seemed odd that the version number bumped with no API interface changes taking place. Handle it however you best see fit. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Kip Macy wrote: In the mean time, you can grab libc_r/uthread/* from -current and rebuild libc_r under -stable. Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a result of a problem with infinite recursion in write. When was this bug fixed? The fix for static initialization of mutexes went into -current on May 23. Other changes went in June 20th. You can check the logs for more details (http://www.freebsd.org/cgi/cvsweb.cgi). Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seg fault in mutex_queue_enq
Daniel Eischen [EMAIL PROTECTED] writes: 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... Just Do It (tm). At least you could merge the change from [pthread_private.h] 1.20 Sun Jun 20 8:28:08 1999 UTC by jb Diffs to 1.19 In the words of the author: o The polling mechanism for I/O readiness was changed from select() to poll(). In additon, a wrapped version of poll() is now provided. [...] plus the later formatting fixes. As an aside: some files still lack $Id$'s, and someone should `s/REGENTS/AUTHOR/' in all the copyright statements. tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
seg fault in mutex_queue_enq
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 #2 0x8308199 in localtime_r (timep=0x8da164c, p_tm=0x8da1620) at /usr/src/lib/libc_r/../libc/stdtime/localtime.c:1091 #3 0x8273e49 in os_time::now () at time.cpp:241 #4 0x8154ea3 in lyr_time_now () at lyrdate.cpp:105 #5 0x8154487 in DateTimeStampEasyRead () at lyrdate.cpp:53 #6 0x80df9de in lyris_InMail::appendTransact (this=0x8da2e0c, setti...@0x8da2818) at inmail.cpp:798 #7 0x80cb47f in lyris_OneIncoming::AppendToInMailTransact (this=0x8da2d20, messa...@0x8da2818) at incoming.cpp:592 #8 0x808b376 in lyris_OneIncoming::do_command_Subscribe (this=0x8da2d20, defaultemailaddre...@0x8da2aec, arealna...@0x8da2afc, ali...@0x8da2d44, theseoptio...@0x8da29ac) at inclserv.cpp:916 #9 0x80c4fa5 in lyris_OneIncoming::command_Subscribe (this=0x8da2d20, defaultemailaddre...@0x8da2aec, defaultrealna...@0x8da2afc, ali...@0x8da2d44, possiblepasswor...@0x8da29ac) at inclsrv2.cpp:44 #10 0x8083b71 in lyris_OneIncoming::process_listserv (this=0x8da2d20) at inclserv.cpp:273 #11 0x80c9007 in lyris_OneIncoming::go (this=0x8da2d20) at incoming.cpp:346 #12 0x80cb0f0 in DoProcessOneIncomingMessage (message...@0x8da2fb0) at incoming.cpp:566 #13 0x80cad5e in ProcessOneIncomingMessage (arg=0x92bacc0) at incoming.cpp:541 #14 0x8285836 in _internal_thread_wrapper (parameter=0x92bace0) at thread.cpp:263 #15 0x82f158e in _thread_start () at /usr/src/lib/libc_r/uthread/uthread_create.c:250 #16 0x0 in ?? () Current language: auto; currently c (gdb) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
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 eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
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. Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a result of a problem with infinite recursion in write. When was this bug fixed? Thanks. -Kip Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seg fault in mutex_queue_enq
Kip Macy wrote: In the mean time, you can grab libc_r/uthread/* from -current and rebuild libc_r under -stable. Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a result of a problem with infinite recursion in write. When was this bug fixed? The fix for static initialization of mutexes went into -current on May 23. Other changes went in June 20th. You can check the logs for more details (http://www.freebsd.org/cgi/cvsweb.cgi). Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
