DCHECK in MaybeRetransmitTailLossProbe |
||
Issue descriptionVersion: 54.0.2791.0 (Developer Build) m (32-bit) rev 83a3c26 OS: Windows 7 32-bit What steps will reproduce the problem? (1) Compile with DCHECKs enabled. (2) Load a page in Chrome. I was testing with https://support.google.com/chrome/answer/95669?p=e_awsnap&rd=1 (3) Chrome DCHECKs. What is the expected output? Doesn't DCHECK. What do you see instead? DCHECKs. Please use labels and text to provide additional information. crash/d1c5640200000000 crash/d0f5640200000000 crash/82ab613600000000
,
Jul 8 2016
FWIW this was on a fresh load of Chrome, and I opened history, and then clicked on the URL from the chrome://history page. It seemed to only happen close to a fresh restart of Chrome.
,
Jul 8 2016
,
Jul 17 2016
Looking at the code, it would seem that DCHECK should always be true. I wouldn't expect us to every retransmit a handshake packet via TLP mode. I assume this issue is repeatable? I won't have time to take a close look this coming week due to IETF, but if no one else has time, I can try to repro it the following week. In the worst case, this would cause handshakes to fail in cases they wouldn't, because the retransmission timer was ending up in TLP mode when it should be in handshake mode.
,
Sep 21 2016
I looked into this more, and I think rch may have solved it with some previous changes to neuter all retransmittable handshake packets once the handshake was confirmed. Can anyone confirm whether this is still an issue? |
||
►
Sign in to add a comment |
||
Comment 1 by wfh@chromium.org
, Jul 8 2016666 if (!handshake_confirmed_) { 667 DCHECK(!it->has_crypto_handshake); <- DCHECKing here. 668 }