Repository navigation
AssertionError in TLS module #22618
Description
Activity
Hi @tjconcept — you'll need to upgrade to 10.8.0 or 10.9.0. There was a bug in earlier versions related to integer overflow.
There’s a very good chance this was fixed by #22214 in v10.9.0.Edit: Oops, @apapirovski’s comment did not show. Anyway, I agree. 😄
- added a commit that references this issue
on Aug 31, 2018 I upgraded straight away and restarted, so I'll just be looking out for this.
Does this also explain why both processes crashed simultaneously? I'm slightly worried what that might mean to a cluster running this way..
What's the proper process for this report?
- added a commit that references this issue
on Sep 3, 2018 Does this also explain why both processes crashed simultaneously?
@tjconcept The issue would usually occur after 2^31 milliseconds after the process started, or 24.855 days. The processes probably did not fail exactly simultaneously, though.
Thanks. It ran for 37 days in both instances. Both had the TLS connection open from the beginning.
- added a commit that references this issue
on Sep 3, 2018 Does this also explain why both processes crashed simultaneously?
Since they had a mutual TLS connection, when the handshake renewal was initiated, the assertion got triggered on both and that led to the crash. That code path only runs in timers (where it wouldn't crash) and in TLS, where it would.
I'm going to close this out since there's nothing else that can be done but feel free to reopen if you feel like we haven't addressed sufficiently.
- added 2 commits that reference this issue
on Sep 5, 2018
This happened identically on two processes running for several weeks. They had a mutual TLS connection over
localhost(using thetlsmodule) with regular data between the two. I do not believe any new code paths in the code was triggered, so I assume the bug is timing or leaking related. I can't immediately reproduce it.I'm sorry I can't provide more details, but at least this is a signal that there's something here.