Chrome/linux stable doesn't load any pages after restarting chrome |
|||||||||
Issue descriptionOn my google linux box, no pages load after updating chrome to latest m62 stable. Firefox works fine. curl works fine. I tried closing chrome, killing all chrome processes in `ps aux` and starting again. Still no dice. Maybe something with proxy scripts? about:net-internals has quite a few red URL_REQUESTS all looking kind of like 56: URL_REQUEST http://check.googlezip.net/generate_204 Start Time: 2017-10-26 11:24:09.614 t=0 [st=0] +REQUEST_ALIVE [dt=?] --> has_upload = false --> is_pending = true --> load_flags = 2 (BYPASS_CACHE) --> load_state = 0 (IDLE) --> method = "GET" --> net_error = -1 (ERR_IO_PENDING) --> status = "IO_PENDING" --> url = "http://check.googlezip.net/generate_204" t=326 [st=0] +REQUEST_ALIVE [dt=?] --> has_upload = false --> is_pending = true --> load_flags = 4356 (MAIN_FRAME_DEPRECATED | SKIP_CACHE_VALIDATION | VERIFY_EV_CERT) --> load_state = 0 (IDLE) --> method = "GET" --> net_error = -1 (ERR_IO_PENDING) --> status = "IO_PENDING" --> url = "https://mail.google.com/mail/u/0/#inbox/15d3e98e7ddd28fd" I have this open and can run diagnoses if there's interest, for a few more hours.
,
Oct 26 2017
[+nharper] The only two sockets in that CL are stuck in SSL_GET_CHANNEL_ID. Do HTTP URLs work? Making this a ReleaseBlock-Stable, as a completely borked Chrome is a pretty big deal, even if it's uncommon.
,
Oct 26 2017
Nevermind about HTTP URLs - HTTP requests are going through an SSL proxy, so they wouldn't, even if it's an SSL issue.
,
Oct 26 2017
(I'll have to leave this machine in 90 minutes and won't get back to it before some time in January, so please let me know if there's anything else you'd like me to pull.)
,
Oct 26 2017
,
Oct 26 2017
Here are some thoughts of possible things to try: Does this reproduce on your machine with a different --user-data-dir? Does this reproduce with the same profile, but using chromium built at the same revision/branch (possibly using a copy of the profile directory)? If this does not reproduce with a different profile, does it reproduce with the same profile, but with the "Origin Bound Certs" file in the profile removed (backing up this file would be nice if removing it does fix the problem)? If removing "Origin Bound Certs" fixes the problem, it would be nice to know what went wrong with it to fix importing/migrating the file.
,
Oct 26 2017
With --user-data-dir=/tmp, pages load fine. I renamed the three Origin Bound Certs files: .config/google-chrome/Guest Profile/Origin Bound Certs .config/google-chrome/Profile 1/Origin Bound Certs .config/google-chrome/Default/Origin Bound Certs It still reproduces after this. I'm trying to build chromium with that revision.
,
Oct 26 2017
I built chrome at that version (`git checkout -b release_branch 62.0.3202.62`). args.gn: use_goma=true is_official_build=true is_component_build=false is_debug=false I made a copy of my user data dir and pointed my locally-built chrome at it: out/gn/chrome --user-data-dir=$HOME/google-chrome-profile Nothing loads there either.
,
Oct 26 2017
I cleared cookies and so on and zipped up my user data dir and put it here: https://drive.google.com/a/google.com/file/d/1I0Ssl4ZfxvqZFiA24NdRY7192OBAB3kD/view?usp=sharing My locally built chromium can repro with that; hopefully yours can too.
,
Oct 27 2017
I attempted a repro with the attached user data dir and a build of chromium on linux at that version (checking out that tag and building with those gn args), but so far it appears I haven't reproed it. There do appear to be different proxy configurations between my attempted repro and what's in the netlog (my repro has an HTTP URL for the PAC script, while the attached netlog has a data: URL). I would like to track down what's going wrong here, but without access to the machine where it repros (and no other known reports of this issue), I'm removing the ReleaseBlock-Stable label.
,
Oct 27 2017
Looks like I'll likely be back in the office to pick up a package some time next week. If there are quick diagnostics you want me to collect, I could do that.
,
Oct 27 2017
I think the easiest approach would be for me to put together a patchset that logs more information. I'll link to that on this bug. Would that work for quick diagnostics (it would require rebuilding), or does that take too long?
,
Oct 27 2017
That's fine, I already have a local chrome build at m62. Rebuilding that just takes a few minutes.
,
Nov 2 2017
Attached is a patch that adds more logging (some to netlog, some to stderr). If you have time to apply that patch and build and run, I'd be interested in another net log (you can pass --log-net-log=/path/to/some/file.json to have it log from startup) and whatever chrome prints to stdout/stderr.
,
Nov 2 2017
The patch is now uploaded as https://chromium-review.googlesource.com/c/chromium/src/+/752122
,
Feb 6 2018
I had to reboot my linux machine, and now it works :-( |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by mmenke@chromium.org
, Oct 26 2017