68830 - tstclient exits with 0 after bad passwd, TLS, require auth

Status: RESOLVED FIXED

(NSS :: Test, defect, P2)

Description

[Sonja Mirtitsch]

This happened twice in 30 testruns on greasybear.

The error message is misleading, since the expected return code is 134 for NT
and 254 for Unix.


***** TLS Require client auth (bad password) ****
selfserv -v -p 8443 -d
w:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/GREASYBEAR.23/server
-n GREASYBEAR.red.iplanet.com -w nss -r -r -i
C:/DOCUME~1/sonmi/LOCALS~1/Temp/tests_pid.1216 & tstclnt -p 8443 -h GREASYBEAR
-q -d
w:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/GREASYBEAR.23/client
redir from
W:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/security/nss/tests/ssl/sslreq.txt
W:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/GREASYBEAR.23/client
tstclnt -p 8443 -h GREASYBEAR -f -d
w:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/GREASYBEAR.23/client
-w bogus -n TestUser redir from
W:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/security/nss/tests/ssl/sslreq.txt
tstclnt: write to SSL socket failed: TCP connection reset by peer.
FAILURE: test TLS Require client auth (bad password) produced a returncode of 0,
expected is 254 O_CRON =

Comment 1

[Wan-Teh Chang]

Nelson, could you look at this test failure on Windows 2000?

We will hold the 3.2 release until this test failure is
understood or fixed.

Comment 2

[Sonja Mirtitsch]

The failure occured once with a Win95 OPT and once on a WinNT DBG build.
Tests are running on SonjaNT and Clio now.

Comment 3

[Wan-Teh Chang]

The source code of tstclnt.c showed that the process
should exit with status -2 if PR_Write failed.  So I
don't understand why we saw it exit with 0.

Comment 4

[Wan-Teh Chang]

OK, after studying the tstclnt source code and comparing
the output.log files of a successful and a failed test runs,
I concluded that:
1. The PR_Write() call in tstclnt has always failed with
   the "TCP connection reset by peer" error on Windows.
   So in that sense, that error is the expected error.
2. The only difference is that in a failed run, tstclnt
   exits with status 0 while in a successful run,
   tstclnt exits with status 134 (on Windows).  Note that
   the main() function of tstclnt.c returns -2.  The expected
   exit status is 254, which is -2 & 0xff.  (A waiting parent
   process can only retrieve the range of 0 through 255 of the
   exit status of a child process.  See the exit man page at
   http://www.opengroup.org/onlinepubs/007908799/xsh/_exit.html.)
   It is not clear how Windows arrives at the value 134 from -2.
3. Our test script ssl.sh attempts to work around the problem
   that we cannot retrieve the correct non-zero exit status on
   Windows.  So the only distinction we can make on Windows is
   0 vs. nonzero exit status.  This bug shows that we can't even
   reliably make this distinction.

Therefore, my assessment of this bug is that it is a bug in
either tstclnt (it should return 0 through 255, not a negative
number) or MKS Korn Shell on Windows 2000.  I propose that
- this bug not block the 3.2 release; and
- this bug be deferred to 3.3, with priority P1.

I'd like Bob, Nelson, and Sonja to review the above and
indicate whether they agree with or object to my proposal.

Comment 5

[Sonja Mirtitsch]

I agree with Wan-Teh, this bug should not defer the release, I would not even
make it a P1 bug.

Additional 82 testruns yesterday were not able to reproduce the problem (32
greasybear, where we saw the problem on the 13th, 36 sonjaNT and 14 clio)

Although I would not know how network problems could interfere with a return
code, I noted that on 2/13 when we saw the failures, the network was very instable. 

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I think this bug should be split into two bugs, one for the exit 
status and another for the PR_Write failure.  The PR_Write bug 
can be assigned to me.

Comment 7

[Sonja Mirtitsch]

Actually I filed this bug on the "exitcode 0 after bad password" problem, and
the bug #68869 on the unexpected different bahavior, which I had thougt to
include the PR_WRITE problem, asides from the exit after the PR_WRITE failure.
I might not fully understand the PR_WRITE problem, so please Nelson file the
PR_WRITE bug.

Comment 8

[Wan-Teh Chang]

OK, I am going to use this bug report for the exit
status problem and assigning the bug to Sonja.

Sonja already filed another bug report for the
PR_Write failure (bug #68869).  I'm assigning that
bug to Nelson.

Comment 9

[Sonja Mirtitsch]

*** Bug 68734 has been marked as a duplicate of this bug. ***

Comment 10

[Sonja Mirtitsch]

A workaround for the exit status bug is in place in the scripts.
The other bug is assigned to Nelson, mrking fixed