The OS is HP-UX 11.00 (both 32-bit and 64-bit). The test machines are orville.mcom.com (32-bit) and biggayal.mcom.com (64-bit). The NSPR release is 3.1.1. The servr_ku, servr_kk, and servr_uk tests (both debug and optimized builds) sometimes hang on some HP-UX 11.00 machines. It is rather hard to reproduce, so you may have to write a shell script to run the test repeatedly, like this: while true; do servr_kk echo ok done I can't reproduce the hang on nugget.mcom.com.

This bug may be related to bug #5791: The servr_kk, servr_ku, servr_uk tests (optimized build) sometimes hang on AIX 4.2.

Didn't have time to look into this for NSPR 4.1.

I just got a hang of servr_ku on HP-UX B.11.00 32-bit with an optimized build of NSPR 4.2.2. The stack traces of the threads look similar. Two threads are in _accept_sys() with this stack: #0 0xc01ee600 in _accept_sys () from /usr/lib/libc.2 #1 0xc01f65c0 in accept () from /usr/lib/libc.2 #2 0xc1371bf8 in pt_accept_cont () [... omitted ...] and one thread with this strange stack: #0 0xc0fd6810 in __pth_thread_main () from /usr/lib/libpthread.1 #1 0xc01feb74 in __thread_main () from /usr/lib/libc.2 #2 0xc01ff860 in __syscall_err () from /usr/lib/libc.2 #3 0xc01ee61c in _accept_sys () from /usr/lib/libc.2 The Unix fd's of our sockets are all non-blocking, so those two threads shouldn't be blocking in accept(). The thread with the strange stack looks like a system thread created to handle an error from the accept system call.