Thanks for the report -- can you recreate this behavior and send us net-internals logs? For how to record logs, see https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Ping. lideln@, please supply the requested feeback.

Closing for lack of response.

(If the problem recurs, please file a new bug with a net-internals dump as per c#1.)

Hi again,

Actually I still experience the bug, even after a fresh reinstall of Windows, but I gave up gathering the info because the bug does not happen 100%, and when I see it, it is already too late: when I try to load the page again with net-internals in another tab, the secure connection is instant.

Do you have a way to clear whatever Chrome is gathering when "establishing a secure connection", so that I can reproduce the bug more easily?

I tried rebooting the computer, clearing the cache, opening the site in a private navigation tab... Nothing works... Until next time it bugs. But I will not have net-internals open.

Or another and maybe better solution: do you have a way to clear the info gathered by net-internals older than, say, 30 seconds? And/or to automatically clear the net-internals logged data older than 30 seconds if I leave the tab open?

This way, I could leave the tab open forever, and whenever I encounter the bug, I just clear the old useless gathered data, just to keep the most recent data, and then send it to you.

It would be much helpful!

Thank you,

SSL folks: How can the state that's gathered (server properties?) when establishing a secure connection be cleared?  Will one of the Clear Browsing Data types do it?

That's a general logging question, not just SSL. I don't think we have a way for net-internals to capture a sliding window's worth of data, but I think we need it. There is risk that, due to how global our net stack is, we'll end up dropping important information, but the alternative is we don't get the information at all. (And one can imagine something where, when NetLogs start, we ask all active sources to summarize their current state.)

I'm not sure what comment 7 has to do with comment 6 (Which was asking about logging state, not events).

Regardless, we used to collect a subset of events in the background, and it was so useless (We always asked for a live capture) and complicated that we removed it.  Memory use and overhead of creating JSON objects makes me wonder whether we really want to go back down that road, even ignoring complexity.

Perhaps I'm misunderstanding. It sounds like the original request (comment 5) was for a way to log more recent information because it takes a long time to reproduce. That's not really an SSL-specific concern. Rather keeping net-internals open indefinitely so a repro is captured results in huge logs and net-internals being slow. Beyond that, this use case isn't really well-served today.

about:net-internals has a "Discard old data under memory pressure" option, so you can select that, and leave it running in the background.

We have multiple different interpretations of c#5.  My interpretation was "it seems like the bug is sporadic, but when it *does* happen, I can't just try it again with net-internals logging going on because there's been some state change around making the security connection.  How can I clear that state?"  which is the question I was trying to get answered.

Agreed, the issue of continuing logging has been discussed in many different contexts.  If we need continuous logging to handle this, the proper way to do it is probably the circular logging implemented by dconnol@google.com this past summer (though I think the discard old data under memory pressure is currently available for desktop, so it should totally be tried first).

Oh right, that box. :-) Yeah, that's basically what I meant. Just a very large window, which works.

lideln: Could you perhaps try with that enabled? Thanks!

rdsmith: If it doesn't reproduce on a fresh Chrome, clearing the state is probably not going to work. I think we want the opposite, since it may be dependent on some state already set up. (Or maybe it's just the OS cert verifier getting wedged, I dunno.)

Good point.  Ok, I'll jump on the "Discard old data under memory pressure" bandwagon.

Actually in my comment #5 I was considering two possible options to greatly help reproduce this  bug 100 %:

* Either clearing whatever SSL data is collected during "establishing secure connection", so that it has to go through this process again, which will allow to reproduce the bug at will

* Or allowing to purge (in about:net-internals) data older than, say, 30 seconds, so that I can leave this window open and wait for the bug to appear someday and then I purge the old (useless) data and only keep the fresh one, which is needed to help the dev team solve the bug

I think comments #6 and #7 both are answering to my propositions.

Regarding your suggestion in comments #12 (and others), will Chrome eat my 16GB or ram? And when the bug does reproduce, will I have a 2GB log to send as attachment? :)

@davidben, comment #13: I can reproduce it, but not at will. I don't know what action on Chrome does clear the "SSL data/state". The bug happens on various sites, not just Google sites (as I saw in some other bug reports).

Thank you for providing more feedback. Adding requester "jri@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Could I please have an answer to my questions regarding memory usage of the
proposed solution?

I'm working h24 on my computer and wouldn't want to unnecessarily harm it.

Thank you,

Le sam. 8 oct. 2016 15:05, sheriff… via monorail <
monorail+v2.4164592774@chromium.org> a écrit :

Sadly, I'm not familiar with how memory pressure works on Windows (or anywhere, really, though I could make a guess for Android).  My guess is that yes, it'll eat up your RAM, but then start releasing it when the machine starts swapping.

Eric, Helen: Do either of you know how memory pressure works on Windows?

It's probably worth noting that if you notice things being slow, you can just close the tab and then reopen it to reset things. Memory usage is not a permanent thing.

Maybe it would be easier if the SSL guys could tell us how to purge their
cache? In my opinion it would be an instant fix! Right?

Le mar. 11 oct. 2016 16:54, david… via monorail <
monorail+v2.294852074@chromium.org> a écrit :

I'm afraid the goal of the Chromium bug tracker is to fix bugs in Chrome/Chromium; user support is a ... lower priority :-}.  Having said that, I'm sure some set of "Clear Browsing Data" flags would clear the SSL state too.  I'd guess the cache related ones, but you could play around and see what happens.

Please get the requested logs. There isn't any cache on the SSL side that would cause the connection to do that, so there is something more interesting going on.

(Undoing some of the mistakes sheriffbot made.)

I will. Unfortunately I have no way to force the bug to reproduce at will.
I'll keep you posted when I have some data.
However there HAS to be some cache on the SSL side that prevents the bug
from happening frequently. That's why I was hoping I could get some intel
from the SSL team.
Thanks anyway!

Le mer. 12 oct. 2016 18:10, david… via monorail <
monorail+v2.294852074@chromium.org> a écrit :

Thank you for providing more feedback. Adding requester "davidben@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Resetting needs-feedback.

ping lideln@ for the net logs with the "Discard old data under memory pressure" option.

Closing for lack of response.