1800751 - Enable network.ssl_tokens_cache_use_only_once

Status: RESOLVED FIXED

(Core :: Networking, task, P2)

Description

[Kershaw Chang [:kershaw]]

I'd like to enable network.ssl_tokens_cache_use_only_once, since the test that blocks turning this on is not failed anymore.

https://treeherder.mozilla.org/jobs?repo=try&revision=cea5ccef884356015ed6a85457d5352d591cad1d&group_state=expanded&selectedTaskRun=L2imaPOUTnydjinjEl-hAg.0

Comment 1

[Kershaw Chang [:kershaw]]

Attachment: Bug 1800751 - Enable network.ssl_tokens_cache_use_only_once, r=#necko

Comment 2

[Kershaw Chang [:kershaw]]

I am not sure why, but I've encountered this test failure when setting network.ssl_tokens_cache_use_only_once to true.
I can also reproduce this locally, and this is caused by an assertion failure below.

 0:11.37 pid:59159 Assertion failure: errorCode != 0, at /Users/changkershaw/work/central/security/manager/ssl/TransportSecurityInfo.cpp:118
fix-stacks: error: failed to find x86-64 code in the fat binary `/Users/changkershaw/work/central/objdir/toolkit/library/build/../buildid.o` referenced by `/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL`
Initializing stack-fixing for the first stack frame, this may take a while...
 0:11.70 pid:59159 #01: mozilla::psm::TransportSecurityInfo::SetCanceled(int) (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x58c9db8)
 0:11.70 pid:59159 #02: (anonymous namespace)::checkHandshake(int, bool, PRFileDesc*, nsNSSSocketInfo*) (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x5903888)
 0:11.70 pid:59159 #03: mozilla::net::nsSocketTransport::IsAlive(bool*) (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x4e4654)
 0:11.70 pid:59159 #04: non-virtual thunk to mozilla::net::nsSocketTransport::IsAlive(bool*) (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x4e46e0)
 0:11.70 pid:59159 #05: mozilla::net::nsHttpConnection::IsAlive() (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x950644)
 0:11.70 pid:59159 #06: mozilla::net::nsHttpConnection::CanReuse() (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x9504e4)
 0:11.70 pid:59159 #07: mozilla::net::ConnectionEntry::PruneDeadConnections() (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x813d04)
 0:11.70 pid:59159 #08: mozilla::net::nsHttpConnectionMgr::OnMsgPruneDeadConnections(int, mozilla::net::ARefBase*) (/Users/changkershaw/work/central/objdir/toolkit/library/build/XUL + 0x95cb28)

I've tried to understand what happened in checkHandshake function and I summarize some things below:

1. This seems to be only happened with an idle connection, which is a connection that completes handshake but never send or receive any data.
2. checkHandshake was called three times, the first two times had bytesTransfered be -1 and originalError be PR_WOULD_BLOCK_ERROR. The last time had bytesTransfered be 0 and originalError also 0.
3. This assertion was hit when checkHandshake was called at the last time.
4. For some reasons, the variable handleHandshakeResultNow was true even if the TLS handshake is done.
5. Somehow the variable wantRetry was set to true here, so we set bytesTransfered to -1.
6. In the end, SetCanceled() is called with originalError 0, so we crashed.

I really don't know how to fix this. Dana, do you probably have an idea?
Thanks.

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Not that this helps, but that looks like bug 1795831. I would try with the patches from bug 1791633 - hopefully either the reorganization fixed the issue (I suspect a race condition) or the added assertions will point to where the problem is (perhaps something is using the socket control off the socket thread).

Comment 4

[Kershaw Chang [:kershaw]]

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #3)

Not that this helps, but that looks like bug 1795831. I would try with the patches from bug 1791633 - hopefully either the reorganization fixed the issue (I suspect a race condition) or the added assertions will point to where the problem is (perhaps something is using the socket control off the socket thread).

Thanks Dana. This is exactly the same as bug 1795831. I assume enabling network.ssl_tokens_cache_use_only_once changes the timing, so we hit this test failure more often.

Comment 5

[Kershaw Chang [:kershaw]]

Attachment: Bug 1800751 - Disable network.ssl_tokens_cache_use_only_once for test_proxy_cancel.js, r=#necko

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6f3bb87923ba
Enable network.ssl_tokens_cache_use_only_once, r=necko-reviewers,valentin
https://hg.mozilla.org/integration/autoland/rev/b70f2f3aaabd
Disable network.ssl_tokens_cache_use_only_once for test_proxy_cancel.js, r=necko-reviewers,valentin

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/6f3bb87923ba
https://hg.mozilla.org/mozilla-central/rev/b70f2f3aaabd