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

Issue 792818 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Bug in chrome browser when open pdf

Reported by gidb...@gmail.com, Dec 7 2017

Issue description

Chrome Versio: 62.0.3202.94
URL : http://www.mrsk-sib.ru/files/storage/00/03/66/65c52d.pdf
Behavior in Firefox 3.x/4.x: working

When the file is opened and when it is refreshed with Ctrl-F5 (or F5), then the file is not visible. Repeat some 10-15 times.

 
screen.png
88.6 KB View Download
Cc: sc00335...@techmahindra.com
Components: Internals>Plugins>PDF
Labels: -Type-Bug -Pri-3 hasbisect-per-revision Triaged-ET ReleaseBlock-Stable M-64 Needs-Triage-M62 OS-Linux OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: wolenetz@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version  62.0.3202.94 and on latest stable 63.0.3239.84 using Ubuntu 14.04,Windows 10 and Mac 10.13.1. But issue is fixed on latest canary 65.0.3258.0. Hence providing reverse bisect info.

Last Bad Build: 64.0.3253.3 
First Good Build: 64.0.3254.0 

You are probably looking for a change made after 512535 (known good), but no later than 512536 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/6bf6f43cc7ef43068612550084c5870d0f28383b..f1b815290d83b4fbe74c6b194d0c822efca7f361

Probably fixed by  https://chromium-review.googlesource.com/742452

@wolenetz: Please confirm whether it is safe to merge to M64 if applicable.

Adding RB-stable for M64. Please remove if not the case.

Thanks!
Labels: -Pri-1 -ReleaseBlock-Stable -Type-Bug-Regression -M-64 OS-Chrome Pri-2 Type-Bug
Owner: ----
Status: Untriaged (was: Assigned)
I can't reproduce this on 64.0.3278.0 on Linux. With 62.0.3202.94 on Linux, even the initial load is blank. No need to reload.

The reverse bisect from comment 1 is incorrect. r512536 couldn't possibly make a difference here.
Since the bug happens in a flaky manner, bisecting is more difficult than normal. I think pressing ctrl + F5 can trigger the bug slightly more often.
Cc: shivanisha@chromium.org
Components: Internals>Network>Cache
I've definitely observed failure at r512592. Since r512592 is known to exhibit this problem, I retried at that revision and it took 27 reloads to reproduce the issue again. Thus bisecting this is really unreliable.

Trying this with a debug build, I got a crash in http_cache.cc after reloading ~10 times:

[142347:142390:1208/165910.846116:FATAL:http_cache.cc(897)] Check failed: !entry->writers. 
#0 0x7f34f80b6c0d base::debug::StackTrace::StackTrace()
#1 0x7f34f80b503c base::debug::StackTrace::StackTrace()
#2 0x7f34f813cbfa logging::LogMessage::~LogMessage()
#3 0x7f34f5d1d509 net::HttpCache::DoneWithEntry()
#4 0x7f34f5d34b3f net::HttpCache::Transaction::DoneWithEntry()
#5 0x7f34f5d34604 net::HttpCache::Transaction::~Transaction()
#6 0x7f34f5d34b79 net::HttpCache::Transaction::~Transaction()
#7 0x7f34f62d68b0 net::URLRequestHttpJob::DestroyTransaction()
#8 0x7f34f62d660a net::URLRequestHttpJob::Kill()
#9 0x7f34f62ac65a net::URLRequest::DoCancel()
#10 0x7f34f62a4f4e net::URLRequest::CancelWithError()
#11 0x7f34f29c0bb5 content::ResourceLoader::CancelRequestInternal()
#12 0x7f34f29c139c content::ResourceLoader::OutOfBandCancel()
#13 0x7f34f29bcae2 content::ResourceHandler::OutOfBandCancel()

So I wonder if that may be the issue here. Calling it a day. I've spent a hour on and off hitting reload repeatedly.
Also, I tried saving the PDF to /tmp and then loading file:///tmp/65c52d.pdf, and I have never seen that fail. So I suspect this is a bug in the network stack.
(I was OoO Friday; I concur with c#2.)
Owner: shivanisha@chromium.org
Status: Assigned (was: Untriaged)
Assigning to myself based on the stack trace.
Issue 784458 has been merged into this issue.
Great. Thanks for looking into this.
Project Member

Comment 11 by bugdroid1@chromium.org, Dec 14 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ed8d6ebc333c49e3abd5e185a3377a87877b98c

commit 7ed8d6ebc333c49e3abd5e185a3377a87877b98c
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Thu Dec 14 23:28:39 2017

HttpCache - Writers and Readers should be mutually exclusive.

There is a combination of simultaneous transactions for an entry, namely
a READ transaction followed by a READ-WRITE transaction that was
violating the mutual exclusiveness of Readers and Writers. This violation
was happening even less frequently because the second transaction being
READ-WRITE can only happen for a range request. This CL fixes the
issue.
HttpCache.RangeGET_DoNotCreateWritersWhenReaderExists

TEST: net_unittests --gtest_filter=
Bug:  792818 
Change-Id: I3a98fb8de2cd521210077e4baf9460fe91232eec
Reviewed-on: https://chromium-review.googlesource.com/825802
Reviewed-by: Randy Smith <rdsmith@chromium.org>
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524229}
[modify] https://crrev.com/7ed8d6ebc333c49e3abd5e185a3377a87877b98c/net/http/http_cache.cc
[modify] https://crrev.com/7ed8d6ebc333c49e3abd5e185a3377a87877b98c/net/http/http_cache_unittest.cc

Status: Fixed (was: Assigned)

Sign in to add a comment