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

Issue 715913 link

Starred by 8 users

Issue metadata

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



Sign in to add a comment

Regression: Browser crashes on navigating to amazon.in

Project Member Reported by keerthan...@techmahindra.com, Apr 27 2017

Issue description

Chrome Version:60.0.3082.0
OS: Ubuntu 14.04

What steps will reproduce the problem?
(1)Launch chrome and  go to amazon.in and let it load >> Now observe


Expected: Chrome should not crash on navigating to amazon.in
Actual: Instead chrome crashes.

This is a regression issue broken in M60. Will update other info soon.

Crash ids: 462857ae80000000 , 1910d7ae80000000
 
Labels: ReleaseBlock-Dev OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on Mac OS 10.12.4 using chrome latest dev #60.0.3082.0. Soon will update the windows behavior as well.

Stack Trace:
--------------
Thread 21 CRASHED [SIGSEGV @ 0x00000008 ] MAGIC SIGNATURE THREAD
Stack Quality96%Show frame trust levels
0x00007fd2c632d185	(chrome -hashtable_policy.h:1028 )	net::HttpCache::DoneReadingFromEntry(net::HttpCache::ActiveEntry*, net::HttpCache::Transaction*)
0x00007fd2c63380ed	(chrome -http_cache_transaction.cc:451 )	net::HttpCache::Transaction::DoneReading()
0x00007fd2c6482c36	(chrome -url_request_http_job.cc:1388 )	net::URLRequestHttpJob::DoneReading()
0x00007fd2c63eed94	(chrome -url_request_job.cc:689 )	net::URLRequestJob::SourceStreamReadComplete(bool, int)
0x00007fd2c63eec83	(chrome -url_request_job.cc:212 )	net::URLRequestJob::Read(net::IOBuffer*, int)
0x00007fd2c63e9277	(chrome -url_request.cc:766 )	net::URLRequest::Read(net::IOBuffer*, int)
0x00007fd2c507c689	(chrome -resource_loader.cc:685 )	content::ResourceLoader::ReadMore(bool)
0x00007fd2c507ca05	(chrome -resource_loader.cc:677 )	content::ResourceLoader::PrepareToReadMore(bool)
0x00007fd2c507d17d	(chrome -resource_loader.cc:660 )	content::ResourceLoader::CompleteResponseStarted()
0x00007fd2c507b1b9	(chrome -resource_loader.cc:428 )	content::ResourceLoader::OnResponseStarted(net::URLRequest*)
0x00007fd2c63ef6a5	(chrome -url_request_job.cc:521 )	net::URLRequestJob::NotifyHeadersComplete()
0x00007fd2c6484f38	(chrome -url_request_http_job.cc:432 )	net::URLRequestHttpJob::NotifyHeadersComplete()
0x00007fd2c6484aea	(chrome -url_request_http_job.cc:768 )	net::URLRequestHttpJob::SaveCookiesAndNotifyHeadersComplete(int)
0x00007fd2c6484633	(chrome -url_request_http_job.cc:931 )	net::URLRequestHttpJob::OnStartCompleted(int)
0x00007fd2c632ec8b	(chrome -callback.h:91 )	net::HttpCache::Transaction::DoLoop(int)
0x00007fd2c4ecba63	(chrome -callback.h:80 )	base::internal::Invoker<base::internal::BindState<base::Callback<void (ContentSetting), (base::internal::CopyMode)1, (base::internal::RepeatMode)1>, ContentSetting>, void ()>::Run(base::internal::BindStateBase*)
0x00007fd2c62524df	(chrome -callback.h:91 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x00007fd2c61e628f	(chrome -message_loop.cc:423 )	base::MessageLoop::RunTask(base::PendingTask*)
0x00007fd2c61e66b7	(chrome -message_loop.cc:434 )	base::MessageLoop::DeferOrRunPendingTask(base::PendingTask)
0x00007fd2c61e5de5	(chrome -message_loop.cc:527 )	base::MessageLoop::DoWork()
0x00007fd2c61e8474	(chrome -message_pump_libevent.cc:219 )	base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)
0x00007fd2c62047ed	(chrome -run_loop.cc:37 )	base::RunLoop::Run()
0x00007fd2c4eec61d	(chrome -browser_thread_impl.cc:278 )	content::BrowserThreadImpl::IOThreadRun(base::RunLoop*)
0x00007fd2c4eec267	(chrome -browser_thread_impl.cc:313 )	content::BrowserThreadImpl::Run(base::RunLoop*)
0x00007fd2c6226abe	(chrome -thread.cc:333 )	base::Thread::ThreadMain()
0x00007fd2c6222843	(chrome -platform_thread_posix.cc:71 )	base::(anonymous namespace)::ThreadFunc(void*)
0x00007fd2c3ae3183	(libpthread-2.19.so + 0x00008183 )	

Manual Bisect Info:
====================
Good Build:60.0.3081.0
Bad Build: 60.0.3082.0

NOTE:Issue is not seen in Windows

Comment 3 by ajha@chromium.org, Apr 27 2017

Cc: jkarlin@chromium.org
Components: -UI Internals>Network>Cache
Owner: shivanisha@chromium.org
Status: Assigned (was: Untriaged)
Just to update this is #1 browser crash on the latest Mac canary(60.0.3082.0- 8 crashes from 8 clients) based on the available crash data. 

Based on code search on 'http_cache_transaction.cc' suspecting: https://codereview.chromium.org/2721933002.

shivanisha@: Could you please take a look at this.

Link to the list of the OS/Builds:
==================================
https://goto.google.com/yzvjy
Just to update this issue.
Seen another issue with simiar stack trace for the below magic signature:

Magic Signature: 'net::PartialData::CacheRead'

This crash seen on latest Mac Canary#60.0.3082.0 & seen 5 Crashes from 5 clents so far.

Link to list of builds:
----------------------
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27net%3A%3APartialData%3A%3ACacheRead%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productname

shivanisha@: Could you please take a look at this.

Thank you..!!

Comment 5 by ajha@chromium.org, Apr 27 2017

Cc: manoranj...@chromium.org bustamante@chromium.org
Labels: OS-Windows
Crashes are seen on Windows canary version(60.0.3082.0) as well in the crash server.

Comment 6 by ajha@chromium.org, Apr 27 2017

Labels: -Pri-1 Stability-Sheriff-Desktop Pri-0
This is supercrashy on the latest canary(60.0.3082.0) and almost top 10 magic signature variants are http cache related.

Looping stability sheriff and punting to P0 to get the suspected CL reverted.
This CL has been reverted. I am looking into the issue. Thanks
Labels: -Pri-0 Pri-1

Comment 10 by w...@chromium.org, Apr 27 2017

Labels: -Stability-Sheriff-Desktop
Thanks for the quick response, Shivani!
 Issue 716048  has been merged into this issue.
shivanisha@, can you please merge this CL to 3082? I would like to trigger a new canary from the same branch.

PS: You do not need to follow any merge approval process since 3082 is yet to be branched officially.

Thank you!
Labels: -Needs-Bisect
https://codereview.chromium.org/2850613002/ created for merging
Project Member

Comment 15 by bugdroid1@chromium.org, Apr 27 2017

Labels: merge-merged-3082
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0e97dc17b154f15e5566ac5079548402ab02e238

commit 0e97dc17b154f15e5566ac5079548402ab02e238
Author: shivanisha <shivanisha@chromium.org>
Date: Thu Apr 27 20:03:45 2017

Revert of HttpCache::Transaction layer allowing parallel validation (patchset #33 id:800001 of https://codereview.chromium.org/2721933002/ )

Reason for revert:
Breaks tricky-tot-chrome-pfq-informational audio_CrasSanity autotest: https://uberchromegw.corp.google.com/i/chromeos.chrome/builders/tricky-tot-chrome-pfq-informational/builds/4271

TBR=asanka@chromium.org,jkarlin@chromium.org
BUG= 715913 

Original issue's description:
> This CL is a precursor to allowing shared writing to fix cache lock.
>
> This CL allows transactions to continue to their validation phase even when another
> transaction is the active reader/writer. After the validation phase, if its a match
> the transaction might wait till the response is written to the cache by the active
> writer. If its not a match the transaction will doom the entry and go to the
> network. In a subsequent CL, the not matching case will create a new entry as well.
>
> BUG= 472740 
>
> Review-Url: https://codereview.chromium.org/2721933002
> Cr-Commit-Position: refs/heads/master@{#467426}
> Committed: https://chromium.googlesource.com/chromium/src/+/1e2e347f957ef889aaee527bb757849f76e8a808

TBR=asanka@chromium.org,jkarlin@chromium.org,rdsmith@chromium.org,shivanisha@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 472740 

Review-Url: https://codereview.chromium.org/2847653002
Cr-Commit-Position: refs/heads/master@{#467556}
(cherry picked from commit ae7fa093c74907efb6c2788208ac05495e960936)

Review-Url: https://codereview.chromium.org/2850613002
Cr-Commit-Position: refs/branch-heads/3082@{#3}
Cr-Branched-From: 190ee07cecf53e3795197cc195b844f7cc15a9ea-refs/heads/master@{#467534}

[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/http_cache.cc
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/http_cache.h
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/http_cache_transaction.cc
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/http_cache_transaction.h
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/http_cache_unittest.cc
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/http_transaction_test_util.cc
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/http_transaction_test_util.h
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/mock_http_cache.cc
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/http/mock_http_cache.h
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/url_request/url_request_quic_unittest.cc
[modify] https://crrev.com/0e97dc17b154f15e5566ac5079548402ab02e238/net/url_request/url_request_unittest.cc

Thank you for the merge. Triggered new canary from 3082.

Comment 17 by ajha@chromium.org, Apr 28 2017

Labels: Needs-triage-Mobile

Comment 18 by ajha@chromium.org, Apr 28 2017

Just to update the behavior regarding the added Needs-triage-Mobile. Issue is not seen on 60.0.3082.0 on (Android 7.0.99;Build/MRA20, Nexus 5 handset & Android 5.0.1; Nexus 10 tablet Build/LRX22C).

Comment 19 by ajha@chromium.org, Apr 28 2017

Labels: TE-Verified-M60 TE-Verified-60.0.3083.0
This is working fine on the latest canary(60.0.3083.0) on Mac OS 10.12.3 and Linux Ubuntu 14.04. Not seeing any crash on navigating to amazon.in.

Adding the verified label, therefore.
Project Member

Comment 20 by sheriffbot@chromium.org, Apr 28 2017

Labels: Fracas FoundIn-M-60
Users experienced this crash on the following builds:

Win Canary 60.0.3082.0 -  8.29 CPM, 170 reports, 162 clients (signature net::HttpCache::Transaction::~Transaction)
Win Canary 60.0.3082.0 -  54.30 CPM, 1113 reports, 1001 clients (signature net::HttpCache::Transaction::DoCacheWriteData)
Win Canary 60.0.3082.0 -  3.71 CPM, 76 reports, 75 clients (signature net::HttpCache::DoneWithEntry)
Win Canary 60.0.3082.0 -  20.03 CPM, 410 reports, 389 clients (signature net::HttpCache::~HttpCache)
Win Canary 60.0.3082.0 -  2.93 CPM, 60 reports, 60 clients (signature std::list<media::AudioInputStream *,std::allocator<media::AudioInputStream *> >::erase)
Win Canary 60.0.3082.0 -  2.24 CPM, 46 reports, 42 clients (signature std::list<media::AudioInputStream *,std::allocator<media::AudioInputStream *> >::clear)
Win Canary 60.0.3082.0 -  18.30 CPM, 375 reports, 357 clients (signature std::_Hash<std::_Uset_traits<media::AudioInputStream *,std::_Uhash_compare<media::AudioInputStream *,std::hash<media::AudioInputStream *>,std::equal_to<media::AudioInputStream *> >,std::allocator<media::AudioInputStream *>,0> >::erase)
Win Canary 60.0.3082.0 -  13.76 CPM, 282 reports, 259 clients (signature net::HttpCache::Transaction::DoCacheReadData)
Win Canary 60.0.3082.0 -  10.59 CPM, 217 reports, 207 clients (signature net::HttpCache::DoneReadingFromEntry)
Win Canary 60.0.3082.0 -  1.90 CPM, 39 reports, 33 clients (signature net::PartialData::CacheRead)
Win Canary 60.0.3082.0 -  1.37 CPM, 28 reports, 28 clients (signature std::_Hash<std::_Uset_traits<media::AudioInputStream *,std::_Uhash_compare<media::AudioInputStream *,std::hash<media::AudioInputStream *>,std::equal_to<media::AudioInputStream *> >,std::allocator<media::AudioInputStream *>,0> >::~_Hash<std::_Uset_traits<media::AudioInputStream *,std::_Uhash_compare<media::AudioInputStream *,std::hash<media::AudioInputStream *>,std::equal_to<media::AudioInputStream *> >,std::allocator<media::AudioInputStream *>,0> >)
Win Canary 60.0.3082.0 -  1.02 CPM, 21 reports, 20 clients (signature net::HttpCache::IsTransactionWritingIncomplete)
Win Canary 60.0.3082.0 -  0.59 CPM, 12 reports, 12 clients (signature net::HttpCache::Transaction::WriteResponseInfoToEntry)
Win Canary 60.0.3082.0 -  0.59 CPM, 12 reports, 12 clients (signature net::HttpCache::Transaction::DoLoop)
Win Canary 60.0.3082.0 -  0.34 CPM, 7 reports, 7 clients (signature net::PartialData::ShouldValidateCache)
Mac Canary 60.0.3082.0 -  8.10 CPM, 34 reports, 34 clients (signature net::HttpCache::IsTransactionWritingIncomplete)
Mac Canary 60.0.3082.0 -  46.72 CPM, 196 reports, 183 clients (signature net::HttpCache::Transaction::DoCacheWriteData)
Mac Canary 60.0.3082.0 -  3.34 CPM, 14 reports, 13 clients (signature net::HttpCache::Transaction::DoLoop)
Mac Canary 60.0.3082.0 -  254.83 CPM, 1069 reports, 891 clients (signature net::HttpCache::DoneReadingFromEntry)
Mac Canary 60.0.3082.0 -  2.38 CPM, 10 reports, 10 clients (signature net::HttpCache::DoneWithEntry)
Mac Canary 60.0.3082.0 -  12.40 CPM, 52 reports, 51 clients (signature net::PartialData::CacheRead)
Mac Canary 60.0.3082.0 -  1.43 CPM, 6 reports, 5 clients (signature net::HttpCache::Transaction::WriteResponseInfoToEntry)
Mac Canary 60.0.3082.0 -  0.24 CPM, 1 reports, 1 clients (signature net::PartialData::ShouldValidateCache)
Mac Canary 60.0.3082.0 -  0.24 CPM, 1 reports, 1 clients (signature net::HttpCache::OnProcessQueuedTransactions)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas
Details on why the issue was coming and the fix:
The DCHECK was getting hit because a HEAD request HttpCache::Transaction for a cached entry was not following the same state in the ActiveEntry as a GET request i.e headers_transaction->done_headers_queue->reader. This was initially done because a HEAD request should not conceptually become a reader, because it does not read any body. What happens in practice is a little different though. Here is what happens:
URLRequestHttpJob does not distinguish between a HEAD and a GET request and sends a request for response body either ways.
If its a fresh request from the network, HttpStreamParser state machine ensures that the Read does not return anything even if server sends a body (https://cs.chromium.org/chromium/src/net/http/http_stream_parser.cc?q=http_stream_parser+package:%5Echromium$&l=1055). 
If its a cached response, HttpCache::Transaction ensures that nothing is read from cached response body (https://cs.chromium.org/chromium/src/net/http/http_cache_transaction.cc?dr=C&l=1826)

Unfortunately, there did not exist any unit tests in URLRequestHttpJob to test a HEAD request.

Thus fixing this issue by making HEAD requests also follow the same states in the ActiveEntry as a GET request. Also adding 3 unit tests that test the HEAD request at the URLRequestHttpJob layer: fresh HEAD request with no content, fresh HEAD request and server also sends content(server error), cached HEAD request. 

comment 21 details the root cause and fix for the initial problem coming in amazon.in. I am looking at the other crashes attributed to this bug. They may or may not be the same issue.
Cc: jmukthavaram@chromium.org
 Issue 716003  has been merged into this issue.
Labels: OS-Android
Just to Update,
               This crash is not observed on Windows,Android, Mac platforms since 60.0.3082.0 builds.

Comment 26 by ajha@chromium.org, May 4 2017

Since there are no crashes seen on the latest canary(60.0.3088.3) and is already verified in C#19 and C#25.

shivanisha@: Could you please close the issue if there is no further work to be done here.

Thank you!
Labels: -Pri-1 Pri-2
Keeping it open till the actual fix lands. Currently the crashes are not coming because the CL was reverted. Decreasing the priority to 2, though.
Status: Fixed (was: Assigned)
Since this crash is no longer occurring and blocking M60 Dev, I am closing this.  Please file a separate bug or track any followup work in the original issue (472740).
Project Member

Comment 29 by bugdroid1@chromium.org, Jun 13 2017

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

commit 8061c420676998bda77caa74581ea8061860f438
Author: shivanisha <shivanisha@chromium.org>
Date: Tue Jun 13 23:35:52 2017

This CL is a precursor to allowing shared writing to fix cache lock.

This CL allows transactions to continue to their validation phase even when another
transaction is the active reader/writer. After the validation phase, if its a match
the transaction might wait till the response is written to the cache by the active
writer. If its not a match the transaction will doom the entry and go to the
network. In a subsequent CL, the not matching case will create a new entry as well.

BUG= 472740 ,  715913 ,  715974 ,  715920 ,  715911 ,  713348 

Review-Url: https://codereview.chromium.org/2721933002
Cr-Original-Commit-Position: refs/heads/master@{#467426}
Committed: https://chromium.googlesource.com/chromium/src/+/1e2e347f957ef889aaee527bb757849f76e8a808
Review-Url: https://codereview.chromium.org/2721933002
Cr-Commit-Position: refs/heads/master@{#479204}

[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_cache.cc
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_cache.h
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_cache_transaction.cc
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_cache_transaction.h
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_cache_unittest.cc
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_transaction.h
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_transaction_test_util.cc
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/http_transaction_test_util.h
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/mock_http_cache.cc
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/http/mock_http_cache.h
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/url_request/url_request_http_job_unittest.cc
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/url_request/url_request_quic_unittest.cc
[modify] https://crrev.com/8061c420676998bda77caa74581ea8061860f438/net/url_request/url_request_unittest.cc

Sign in to add a comment