Closed Bug 1328143 Opened 7 years ago Closed 5 years ago

NSS build mode NISCC_TEST=1 no longer works, assert failures in ssl3con.c

Categories

(NSS :: Test, defect, P3)

3.28
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: KaiE, Unassigned)

Details

NSS has a build flag NISCC_TEST which enables a special build mode, that deliberately allows NSS to produce invalid data, which is used for some special tests, where data is exchanged between a normal NSS build and a NISCC_TEST=1 build.

These tests are executed as a weekly job, in a specially prepared environment that has access to a large amount of test files.


That job no longer works. A large number of core files are generated, and the disks fill up quickly, and execution is stuck.


Below is the stacktrace of one core file that I've picked randomly. It's an assertion failure on line 2806 below.



2781	        if (numRecords == 2) {
2782	            sslBuffer secondRecord;
2783	            rv = ssl_ProtectRecord(ss, ss->ssl3.cwSpec, capRecordVersion, type,
2784	                                   pIn, 1, wrBuf);
(gdb) 
2785	            if (rv != SECSuccess)
2786	                goto spec_locked_loser;
2787	
2788	            PRINT_BUF(50, (ss, "send (encrypted) record data [1/2]:",
2789	                           wrBuf->buf, wrBuf->len));
2790	
2791	            secondRecord.buf = wrBuf->buf + wrBuf->len;
2792	            secondRecord.len = 0;
2793	            secondRecord.space = wrBuf->space - wrBuf->len;
2794	
(gdb) 
2795	            rv = ssl_ProtectRecord(ss, ss->ssl3.cwSpec, capRecordVersion, type,
2796	                                   pIn + 1, contentLen - 1, &secondRecord);
2797	            if (rv == SECSuccess) {
2798	                PRINT_BUF(50, (ss, "send (encrypted) record data [2/2]:",
2799	                               secondRecord.buf, secondRecord.len));
2800	                wrBuf->len += secondRecord.len;
2801	            }
2802	        } else {
2803	            if (cwSpec) {
2804	                /* cwSpec can only be set for retransmissions of DTLS handshake
(gdb) 
2805	                 * messages. */
2806	                PORT_Assert(IS_DTLS(ss) &&
2807	                            (type == content_handshake ||
2808	                             type == content_change_cipher_spec));


The bug can be reproduced on the specially configured Mozilla host
  nss-vm-centos6-1.community.scl3.mozilla.com
user "niscc", see the cronjob with "crontab -l".
Might be a regression caused by bug 1316974. Just because that code was touched there, I have no idea what could be going on.
Kai, can you provide the actual stack trace?
Flags: needinfo?(kaie)
Priority: -- → P3

I think this was a one-time failure, I didn't see it again later.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(kaie)
QA Contact: mwobensmith
Resolution: --- → INVALID

(And I'm no longer maintaining these tests, I don't know if anyone is still running it.)

You need to log in before you can comment on or make changes to this bug.