threads/84483: problems with devel/nspr and -lc_r on 4.x

Mikhail T. mi at
Tue Aug 2 14:00:41 GMT 2005

>Number:         84483
>Category:       threads
>Synopsis:       problems with devel/nspr and -lc_r on 4.x
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-threads
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 02 14:00:37 GMT 2005
>Originator:     Mikhail T.
>Release:        FreeBSD 4.11-STABLE i386
Virtual Estates, Inc.
System: FreeBSD 4.11-STABLE FreeBSD 4.11-STABLE #1: Wed Jul 20 21:04:19 EDT 2005 mi at i386


	The self-tests, which come with NSPR (devel/nspr port) are
	now patched and built to be meaningful.

	The also succeed on FreeBSD-5. On FreeBSD-4 some tests hang
	for ever all (or most) having to do with semaphores.


	Update to the very latest version of the devel/nspr port.
		make build test

	Some tests at the beginning may take a while, but the first
	one to truly hang is nameshm1:

	(gdb) where
	#0  0x280cfeac in semsys () from /usr/lib/
	#1  0x280c7122 in semop () from /usr/lib/
	#2  0x80526d8 in PR_WaitSemaphore ()
	#3  0x804c1d0 in ClientServerTest ()
	#4  0x804c643 in main ()
	#5  0x804b556 in _start ()

	You can kill the hung ones (killall nameshm1) and allow the
	test harness to proceed to the next one (randseed):

	(gdb) where
	#0  0x280dcf38 in __sys_poll () from /usr/lib/
	#1  0x280dc41d in _thread_kern_sched_state_unlock () from /usr/lib/
	#2  0x280dbdd2 in _thread_kern_scheduler () from /usr/lib/
	#3  0x0 in ?? ()

	A thread-developer needs to look at this to either fix -lc_r,
	or point out the bugs in the NSPR or its self-tests.

	The tests are single-file C-programs in


	they are run from their build-area in


	Again, none of these problems exist on 5.x and, presumably,
	6.x (except for the instrumt-test, which crashes on all
	and is currently patched-out from the list).


More information about the freebsd-threads mailing list