New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 719198 link

Starred by 2 users
Status: Untriaged
Owner: ----
Cc:
█ nick@chromium.org
█ irv...@naml.us
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

First 0x4000 bytes of a pdf served from disk cache were zeroes (corruption)

Project Member Reported by nick@chromium.org, May 6 2017 
A friend (also a Googler) reported encountering a PDF that didn't load on Chrome, but worked on other browsers.

The problem appears to be corruption of the cached resource in Chrome's disk cache:

 1. A net-export trace of the PDF load showed that the resource being loaded via a DISK_CACHE_ENTRY event.
 2.  We dumped the contents of his cached file using the following JS snippet: https://gist.github.com/anonymous/0c71c6133ddb9144f5fd0367611d546f
 3. The sizes were identical, but the sha256's didn't match.
 4. Comparing (in a binary diff tool), the dumped pdf and the uncorrupt original, they were identical from offset 0x4000 onward. In the corrupt file, the first 0x4000 bytes were all zeroes.
 5. These pdfs are attached.

Version details:

Google Chrome 58.0.3029.96 (official 2a03c99a5f45c6d507af8eb2345ad68a565d1518-refs/branch-heads/3029@{#787}) 

Mac OS X: 10.12.4 (x86_64)

Active trials:
BrowserScheduler:Default ChromeChannelStable:Enabled ClientSideDetectionModel:Model0 DisallowFetchForDocWrittenScriptsInMainFrame:Control_20161208_Launch DownloadAttributionPerformanceTest:DownloadAttributionEnabled ExpensiveBackgroundTimerThrottling:Enabled4_NoMaxThrottlingDelay ExtensionInstallVerification:Enforce FasterLocationReload:Disabled_Turndown Html5ByDefault:Enabled8 HttpFormWarning:Default InstanceID:Enabled MacAllowBackgroundingProcesses:Default NTPTilesInInstantService:Default NetDelayableH2AndQuicRequests:Default NetProxyPreconnects:Enabled4_NoControl NetworkTimeQueries:Default NoStatePrefetchValidation:PrerenderDisabled OmniboxBundledExperimentV1:StandardR7 PasswordGeneration:Disabled PasswordManagerSettingsMigration:Enable PasswordMetadataFilling:Control PersistentHistograms:Default QUIC:EnabledNoId SettingsEnforcement:enforce_always_with_extensions_and_dse SiteIsolationExtensions:Enabled_100 SubresourceFilter:EnabledForPhishingSites TranslateRankerLogging:TranslateRankerLoggingLaunched UKM:Disabled UMA-Dynamic-Uniformity-Trial:Group6 UMA-Population-Restrict:normal UMA-Uniformity-Trial-1-Percent:group_82 UMA-Uniformity-Trial-10-Percent:group_02 UMA-Uniformity-Trial-100-Percent:group_01 UMA-Uniformity-Trial-20-Percent:group_01 UMA-Uniformity-Trial-5-Percent:group_01 UMA-Uniformity-Trial-50-Percent:default V8Ignition:Default WebFontsInterventionV2:Default
pdf-from-cache-bad.pdf
821 KB Download
pdf-good.pdf
821 KB Download

Comment 1 by mmenke@chromium.org, May 8 2017 

How sure are we this is cache corruption, and not an issue lower down in the stack (Or even a bug in the server?)

Corrupt data is being read from the cache, but did we have good data to start with?

Comment 2 by nick@chromium.org, May 8 2017 

Not certain. The truncation of the file at a page-aligned boundary seemed like it might be a clue as to what layer this could be happening at. Other than that, what I know is in the report.

Since the bug is not repeatable (and the affected user has force-reloaded the document after we completed our analysis), it's probably unlikely that we can do much with this report. Feel free to WillNotFix it, if so.
►

Sign in to add a comment