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

(NeedInfo from)


2 years ago
10 months ago


(Reporter: kaie, Unassigned, NeedInfo)



Firefox Tracking Flags

(Not tracked)




2 years ago
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);
2785	            if (rv != SECSuccess)
2786	                goto spec_locked_loser;
2788	            PRINT_BUF(50, (ss, "send (encrypted) record data [1/2]:",
2789	                           wrBuf->buf, wrBuf->len));
2791	            secondRecord.buf = wrBuf->buf + wrBuf->len;
2792	            secondRecord.len = 0;
2793	            secondRecord.space = wrBuf->space - wrBuf->len;
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
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
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)
You need to log in before you can comment on or make changes to this bug.