Re: seg fault in mutex_queue_enq

Daniel Eischen 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. t

Re: seg fault in mutex_queue_enq

Daniel Eischen <[EMAIL PROTECTED]> 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 mainten

Re: seg fault in mutex_queue_enq

Thomas Gellekum 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

Daniel Eischen 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

Re: seg fault in mutex_queue_enq

Thomas Gellekum <[EMAIL PROTECTED]> 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 [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 betwe

Re: seg fault in mutex_queue_enq

Daniel Eischen 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,

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 giv