Subject: Re: kern/24829
To: Jarle Greipsland <>
From: Chuck Silvers <>
List: netbsd-bugs
Date: 11/09/2005 08:55:29
On Tue, Nov 08, 2005 at 10:00:47AM +0100, Jarle Greipsland wrote:
> Jarle Greipsland <> writes:
> > It is still there.  On a 3.0_BETA kernel from around October
> > 20th, I still got the same panic.  It is not the same system that
> > for which the original problem report was filed, but the current
> > system is also a quad-cpu i386-family system.  Console log below.
> > Please let me know if there is any other information you want me
> > to try and gather.
> Some more data.  I briefly looked in the apache web server logs,
> and noticed some pthread-releated messages.  I don't know whether
> they are related to the panic or not.  Log messages below.
> 					-jarle
> [Tue Nov 08 08:27:39 2005] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
> [Tue Nov 08 08:27:42 2005] [notice] Digest: generating secret for digest authentication ...
> [Tue Nov 08 08:27:42 2005] [notice] Digest: done
> [Tue Nov 08 08:27:42 2005] [notice] Apache/2.0.55 (Unix) mod_ssl/2.0.55 OpenSSL/0.9.7d DAV/2 configured -- resuming normal operations
> [Tue Nov 08 08:27:47 2005] [notice] child pid 19659 exit signal Segmentation fault (11)
> assertion "unreachable" failed: file "/usr/src/lib/libpthread/pthread.c", line 622, function "pthread_exit"
> [Tue Nov 08 08:27:59 2005] [notice] child pid 5309 exit signal Abort trap (6)

these "unreachable" assertions should be fixed with my recent changes to
libpthread.  those have been applied to -current and the 3.x branch so far,
are you running with the latest libpthread?

> assertion "target->pt_state != PT_STATE_RUNNING || target->pt_blockgen != target->pt_unblockgen" failed: file "/usr/src/lib/libpthread/pthread_sig.c", line 812, function "pthread__kill"

this is because the libpthread code does not yet support running with
PTHREAD_CONCURRENCY > 1, as evidenced by the comment right before the

	 * Ensure the victim is not running.
	 * In a MP world, it could be on another processor somewhere.
	 * XXX As long as this is uniprocessor, encountering a running
	 * target process is a bug.
	pthread__assert(target->pt_state != PT_STATE_RUNNING ||
		target->pt_blockgen != target->pt_unblockgen);

I was hoping that at least the kernel would survive this configuration,
but apparently not.  I'll see if I can figure out how to avoid the crash,
but if we can't fix it very quickly then we should consider disabling
PTHREAD_CONCURRENCY > 1 for the 3.0 release.