412808 - Provider and cltsrv tests failed.

Status: NEW

(NSPR :: NSPR, defect)

Description

[Slavomir Katuscak]

From nightly tests:
securityjes5/20080116.1/charm.4-HP-UXB.11.11_64_OPT.OBJ

provider			FAILED

BEGIN TEST: provider (2008-00-16 22:39:12)

PR_CONNECT_RESET_ERROR(-5961), oserror = 32
Assertion failure: sizeof(*descriptor) == bytes, at ../../../pr/tests/provider.c:306
Client/Server started at(0x80000001000076a0): 22:39:12
Server started at(0x8000000100023fe8): 22:39:12
Client started at(0x8000000100047fd8): 22:39:12
main(0x80000001000076a0): waiting for execution interval (10 seconds)

END TEST: provider (2008-00-16 22:39:13)

Probably it's the same problem as bug #386177, but now assertion works and error is reported.

Comment 1

[Slavomir Katuscak]

The same issue occured in cltsrv test, these tests have very similar code, and most probably it's the same reason.

BEGIN TEST: cltsrv (2008-00-20 03:05:01)

PR_CONNECT_RESET_ERROR(-5961), oserror = 32
Assertion failure: sizeof(*descriptor) == bytes, at ../../../pr/tests/cltsrv.c:305
Client/Server started at(0x40004bc0): 03:05:01
Server started at(0x40009e68): 03:05:01
Client started at(0x4000a280): 03:05:01
main(0x40004bc0): waiting for execution interval (10 seconds)

END TEST: cltsrv (2008-00-20 03:05:02)
TEST STATUS: cltsrv = FAILED (errno 6)

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Slavo, Some questions for you.
1) Why did the client's attempt to send get a PR_CONNECT_RESET_ERROR?
2) If you cannot tell from the log output, what additional information
might you want the test programs to output to answer that question?
3) Is the TEST_LOG feature enabled and being used? Do you have its output?

Comment 3

[Slavomir Katuscak]

First time seen failure cltsrv of this test on other OS then HPUX (after fixing bug 386177). Logs from biarritz/SunOS5.10_i86pc_64_DBG.OBJ:

BEGIN TEST: cltsrv (2008-00-20 22:23:35)

PR_PENDING_INTERRUPT_ERROR(-5993), oserror = 0
Assertion failure: NULL != fd, at ../../../pr/tests/cltsrv.c:273
Client/Server started at(0x41b120): 22:23:35
Server started at(0x426af0): 22:23:35
Client started at(0x426e60): 22:23:35
main(0x41b120): waiting for execution interval (10 seconds)
Shutting down(0x41b120): 22:23:45

END TEST: cltsrv (2008-00-20 22:23:45)
TEST STATUS: cltsrv = FAILED (errno 6)

Comment 4

[Slavomir Katuscak]

(In reply to comment #2)
> 1) Why did the client's attempt to send get a PR_CONNECT_RESET_ERROR?

I don't know the reason yet.

> 2) If you cannot tell from the log output, what additional information
> might you want the test programs to output to answer that question?

I came over client part and seems clear for me, server part is more difficult to analyze and manual debugging can help much (but it's difficult to reproduce a problem, because it occurs very rarely).

I noticed in log (bug 386177 comment 3) that there are 2 calls of PR_Accept() function. There is only function Worker() calling PR_Accept(), and from log it seems that there is only one Worker() running. For me it looks that PR_Accept failed (we need to find out why) and this failure is not reported (there is only if ((NULL == fd) && Aborted(PR_FAILURE)) check, so if failure is not PR_PENDING_INTERRUPT_ERROR) it doesn't do anything and continues in next iteration of while cycle. 

> 3) Is the TEST_LOG feature enabled and being used? Do you have its output?
> 

TEST_LOG feature is not enabled by default. There are some more parameters which needs to be set manually. I tested this test with debug parameters (see logs in bug 386177), but it's a bit problem to reproduce failure, because it fails very rarely. Maybe it would be better to modify tests to have verbose output (debug) enabled by default.

Also I noticed that we have there 2 different failures - one is in PR_Send() (description + comment 1) and one is in PR_Socket() (comment 3). PR_Send() failures occured was always seen only on HPUX, PR_Socket is seen now for the first time and it occured on Solaris.

Comment 5

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

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