From owner-freebsd-stable  Mon Jun 28 21:10:22 1999
Delivered-To: freebsd-stable@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4E987151B7; Mon, 28 Jun 1999 21:10:12 -0700 (PDT)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id VAA95594;
	Mon, 28 Jun 1999 21:09:42 -0700 (PDT)
	(envelope-from jkh@zippy.cdrom.com)
To: stable@freebsd.org
Cc: jb@freebsd.org, eischen@vigrid.com
Subject: pthreads in -stable
Date: Mon, 28 Jun 1999 21:09:41 -0700
Message-ID: <95582.930629381@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I can't help but notice that pthread support in -current is *much*
different than that currently in -stable and the reason I ask is that
a certain large, well-known application is having looping problems
within the current libc_r code, to wit:

#0  0x282738e0 in _thread_sys_select () from /usr/lib/libc_r.so.3
#1  0x28272f9d in _thread_kern_select (wait_reqd=1)
    at /a/time/src/lib/libc_r/uthread/uthread_kern.c:816
#2  0x28272876 in _thread_kern_sched (scp=0x0)
    at /a/time/src/lib/libc_r/uthread/uthread_kern.c:376
#3  0x28272a2f in _thread_kern_sched_state (state=PS_SLEEP_WAIT, 
    fname=0x282a4343 "/a/time/src/lib/libc_r/uthread/uthread_nanosleep.c", 
    lineno=72) at /a/time/src/lib/libc_r/uthread/uthread_kern.c:471
#4  0x282841d7 in nanosleep (time_to_sleep=0xbfbfd2bc, 
    time_remaining=0xbfbfd2b4)
    at /a/time/src/lib/libc_r/uthread/uthread_nanosleep.c:72
#5  0x2818fd57 in sleep () from /usr/lib/libc.so.3

When I went to trace this out, I then found that the code to deal with
this case in -current was significantly different than the code in
-stable and it set me to wondering if a MFC was simply in order.  I'm
currently trying to build this product under -current (a very
laborious process) to see if the problem has automagically gone away
with the new libc_r, but even if this fixes it we'll still be screwed
until we MFC since this product has to run under production versions
of the OS and that means 3.3 at the very minimum.

The failure mode is that the thread_sys_select() eventually times out
and falls through some code in thread_kern_sched after which it loops
back and does it all over again.  The code never proceeds past this
point.  If somebody has encountered this specific problem in -stable
and has a fix for it, I'd also be more than happy to have it since it
would give me the freedom to hand this nameless ISV a small patch to
3.2 to get them going again, otherwise that's going to be a more
traumatic cvsup and rebuild away (assuming again that this problem is
even fixed in -current).

Thanks!

- Jordan


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