386314 - Nonblock test failed.

Status: NEW

(NSPR :: NSPR, defect, P3)

Description

[Slavomir Katuscak]

From nightly tests:
securityjes5/20070628.1/workout.2-Linux2.4_x86_glibc_PTH_OPT.OBJ

nonblock./runtests.sh: line 272: 19730 Terminated              ( sleep $TEST_TIMEOUT; kill $test_pid >/dev/null 2>&1 )
			FAILED

BEGIN TEST: nonblock

The serveclient thread created.
accept: EWOULDBLOCK, good
connect: EWOULDBLOCK, good
client connected
accept: succeeded, good
read: EWOULDBLOCK, good
client sent 10 bytes
read: 10 bytes, good
read: EWOULDBLOCK, good
client sent 10 bytes
read: 10 bytes, good
read: EWOULDBLOCK, good
client sent 10 bytes
read: 10 bytes, good
client sent 10 bytes
First Receive:
: PR_WOULD_BLOCK_ERROR(-5998), oserror = 11
First PR_Recv: retVal: 10, Error: -5998

END TEST: nonblock

Comment 1

[Slavomir Katuscak]

Failed also on HPUX in trunk:

BEGIN TEST: nonblock

The serveclient thread created.
accept: EWOULDBLOCK, good
client connected
accept: succeeded, good
read: EWOULDBLOCK, good
client sent 10 bytes
read: 10 bytes, good
read: EWOULDBLOCK, good
client sent 10 bytes
read: 10 bytes, good
read: EWOULDBLOCK, good
client sent 10 bytes
read: 10 bytes, good
read: EWOULDBLOCK, good
client sent 10 bytes
read: 10 bytes, good
client sent 10 bytes
First Receive:
: PR_WOULD_BLOCK_ERROR(-5998), oserror = 246
First PR_Recv: retVal: 10, Error: -5998

END TEST: nonblock

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

This sounds like a broken test program.  
Look up error 11 on Linux and error 246 on HPUX.
If they're EWOULDBLOCK or EAGAIN or EINTR, then 
these test programs are merely being too simplistic,
and the fix is to fix the test program.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

If NSPR had a "test" component, this bug would get that component.

This bug, and the other NSPR bugs like it that were filed in the last few days,
seems to be a defect in the test program and/or test script itself,
or in the system configuration, rather than (or in addition to) a defect 
in the NSPR libraries.  

If there is a defect in the NSPR libraries, these test results do not 
clearly indicate that.  Many of these failures are not occurring in NSPR
test programs at all.  

Have the systems run out of some resource?  
Are they not able to start more processes because the Process table is full?  
Are the failures to start new threads due to the process table being full? 
(Does each thread have its own PID?) 

Comment 4

[Wan-Teh Chang]

This test program relies on accurate timeout to synchronize
the client and server threads.  The intention is to test
not only non-blocking I/O but also I/O timeout.  Since none
of the OS's are real-time OS, if the system is overloaded,
the timeout won't be accurate and the test will fail.

The proper fix is to use synchronization methods (locks
and condition variables) to synchronize the client and
server threads.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.