Curious if you guys have any UMA data for how frequent these http cache read errors are.

The metric (on stable channel) doesn't seem to have any recent regression. Let's flip some labels to get on cache folks radar.

Seems like a serious bug, bumping pri and ccing gavinp.

Interestingly I cleared my cache and I'm *still* seeing examples of this happening

Also looping to chromium//src/net/http/OWNERS for prioritizing.

Uh, why am I assigned? Any reason I should expect to have relevant experience?

Oh, palmer@ and I are on this because we're listed as OWNERS in net/http. Note that we're owners for an extremely narrow scope (`per-file transport_security_state_static.*`, which covers three files) in that folder.

Let's move this into the normal net triage process [1] by setting to Untriaged and adding the explicit `Internals>Network` label to match the triage filter.


[1] https://chromium.googlesource.com/chromium/src/+/master/net/docs/bug-triage.md

this seems like blockfile cache (otherwise the netlog would be slightly different). All I know about blockfile cache is that it mmaps a few files and stores multiple entries in them (one entry if the latter is huge .. afair). So getting an ERR_FILE_NOT_FOUND from reading the already-open file looks unusual. I have no knowledge of MacOS internals/bugs, but one question pops: is it theoretically possible that something cleans and unmaps files from the process? What happens when a process hits the limit of open file descriptors?

This is a cache issue so as net triager I am re-triaging back to cache.

Its out of scope from TE side, hence adding TE-NeedsTriageHelp to addressed further.

This happens to me (and several other users I know of at my employer) with great regularity and happens across virtually every site/page I visit frequently when it appears. Manifests as the following:

1) Visit a page
2) Main page HTML loads and then all child assets (JS/CSS/images) that have cache entries fail to load, leaving the page in an unusable state
3) Reload page
4) Page renders correctly

In (2), the net-internals event log shows near-identical event timelines as in the original bug description, plus the following for the cache request:

t=4223 [st=0] +DISK_CACHE_ENTRY_IMPL  [dt=2]
               --> created = false
               --> key = "https://drive.google.com/_/drive_fe/_/js/k=drive_fe.main.en_US.9kQxQmW5Gog.O/m=sy2g,sy30,sy2t,sy37,sy44,sy3p,sy2x,sy3z,sy3y,sy46,sy39,sy34,sy3b,sy3i,sy3k,sy48,sy4b,sy40,sy4a,sy3q,sy45,sy47,sy3w,sy2c,sy2e,sy2f,sy3u,sy3x,sy42,sy5c,sy4d,sy2d,sy32,sy3j,sy3r,sy4c,sy2,em3,sy3s,sy5d,AuBwMe,sy2a,sy29,sy2w,sy2b,sy2k,sy43,dl/am=2Yj2AK4c/rt=j/rs=AFB8gszGDwIlXYeGrxxoV8yGdYWReQ4WXQ"
t=4223 [st=0]   +ENTRY_READ_DATA  [dt=0]
                 --> buf_len = 4652
                 --> index = 0
                 --> offset = 0
t=4223 [st=0]   -ENTRY_READ_DATA
                 --> bytes_copied = 4652
t=4225 [st=2]   +ENTRY_READ_DATA  [dt=0]
                 --> buf_len = 32768
                 --> index = 1
                 --> offset = 0
t=4225 [st=2]      ENTRY_DOOM
t=4225 [st=2]   -ENTRY_READ_DATA
                 --> net_error = -6 (ERR_FILE_NOT_FOUND)
t=4225 [st=2] -DISK_CACHE_ENTRY_IMPL

I haven't been able to find an environmental cause for this yet but *have* ruled out the Sophos Antivirus we were using (by switching to another AV vendor). I haven't journaled exactly when it happens but it's at least once a week.

Hoping the additional event log from the cache system itself may be of use and that this can get some attention soon :)

skimbrel:
1. what version+channel are you using?
2. wow, do you always use chrome with netlog on?

these parts of netlog did not provide any clue to me. If you see the problem regularly, I'd be tangentially interested how regularly you see such problems if you switch to the "simple cache backend" (about:flags -> simple cache for http -> Enabled). This backends opens and closes many more files in a unit of time, but corruptions are less likely.

@pasko:

1. 58.0.3029.81 on stable channel
2. No. When the problem happens it wipes out cache for a lot of sites at once — so when I see it happen on one page I can turn on netlog by opening chrome://net-internals and then go visit more pages to capture the events.

I am still pretty convinced there's an environmental cause because this only happens to me on my work laptop where there's a bunch of managed-endpoint software running, not on my personal machine at home. Not sure what to go looking for to isolate it and I haven't found a reliable means of reproducing on demand, so it's kinda hard to identify potential causes.

Oops, hit submit too soon.

I've enabled the simple cache backend — will run for a few weeks and see if the problem recurs (usually I see the breakage at least one a week).

Have been running with simple cache for a month now and haven't seen this since. Not really noticing performance changes either. Is this new backend intended to go mainline eventually?

It's mainline on Android and Linux. We hope to bring it to other platforms but there are performance issues that we need to overcome first.