Issue metadata
Sign in to add a comment
|
Chrome_Android: Crash Report - [Renderer kill 97] content::ResourceDispatcherHostImpl::BeginRequest |
||||||||||||||||||||||
Issue descriptionUnable to find the Magic signature in fracus, hence creating from "New Issue Link" Product name: Chrome_Android Magic Signature: [Renderer kill 97] content::ResourceDispatcherHostImpl::BeginRequest Current link: https://crash.corp.google.com/browse?q=product.name%3D'Chrome_Android'%20AND%20product.version%3D'59.0.3050.4'%20AND%20custom_data.ChromeCrashProto.channel%3D'canary'%20AND%20custom_data.ChromeCrashProto.ptype%3D'browser'%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D'%5BRenderer%20kill%2097%5D%20content%3A%3AResourceDispatcherHostImpl%3A%3ABeginRequest'%20AND%20ReportID%3D'2818aa3480000000'&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#3 Search properties: product.name: Chrome_Android product.version: 59.0.3050.4 custom_data.chromecrashproto.channel: canary custom_data.chromecrashproto.ptype: browser custom_data.chromecrashproto.magic_signature_1.name: [Renderer kill 97] content::ResourceDispatcherHostImpl::BeginRequest reportid: 2818aa3480000000 Metadata : Product Name: Chrome_Android Product Version: 59.0.3050.4 Report ID: 2818aa3480000000 Report Time: Mon, 27 Mar 2017 10:07:35 GMT Uptime: 3289134 ms Cumulative Uptime: 0 ms User Email: OS Name: Android OS Version: 0.0.0 Linux 3.10.86-g53f7dd5 #2 SMP PREEMPT Thu Nov 17 22:01:48 CST 2016 aarch64 CPU Architecture: arm64 CPU Info: Stack Trace: ================ Thread 35 CRASHED [DUMP_REQUESTED @ 0x0000007f687ae9dc ] MAGIC SIGNATURE THREAD Stack Quality97%Show frame trust levels 0x0000007f687ae9dc (libchrome.so -exception_handler.cc:666 ) google_breakpad::ExceptionHandler::WriteMinidump() 0x0000007f677921a4 (libchrome.so -breakpad_linux.cc:744 ) DumpProcess 0x0000007f6608e66c (libchrome.so -dump_without_crashing.cc:23 ) base::debug::DumpWithoutCrashing() 0x0000007f66c8da4c (libchrome.so -browser_message_filter.cc:173 ) content::BrowserMessageFilter::ShutdownForBadMessage() 0x0000007f66d47a28 (libchrome.so -bad_message.cc:67 ) content::bad_message::ReceivedBadMessage(content::BrowserMessageFilter*, content::bad_message::BadMessageReason) 0x0000007f66e84764 (libchrome.so -resource_dispatcher_host_impl.cc:1115 ) content::ResourceDispatcherHostImpl::BeginRequest(content::ResourceRequesterInfo*, int, content::ResourceRequest const&, base::Callback<void (content::SyncLoadResult const*), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, int, mojo::AssociatedInterfaceRequest<content::mojom::URLLoader>, mojo::InterfacePtr<content::mojom::URLLoaderClient>) 0x0000007f66e84c70 (libchrome.so -resource_dispatcher_host_impl.cc:910 ) content::ResourceDispatcherHostImpl::OnRequestResourceInternal(content::ResourceRequesterInfo*, int, int, content::ResourceRequest const&, mojo::AssociatedInterfaceRequest<content::mojom::URLLoader>, mojo::InterfacePtr<content::mojom::URLLoaderClient>) 0x0000007f66e84dc0 (libchrome.so -resource_dispatcher_host_impl.cc:880 ) content::ResourceDispatcherHostImpl::OnRequestResource(content::ResourceRequesterInfo*, int, int, content::ResourceRequest const&) 0x0000007f66e7ff60 (libchrome.so -ipc_message_templates.h:40 ) content::ResourceDispatcherHostImpl::OnMessageReceived(IPC::Message const&, content::ResourceRequesterInfo*) 0x0000007f66c8d95c (libchrome.so -browser_message_filter.cc:87 ) content::BrowserMessageFilter::Internal::DispatchMessage(IPC::Message const&) 0x0000007f66c8df4c (libchrome.so -browser_message_filter.cc:67 ) content::BrowserMessageFilter::Internal::OnMessageReceived(IPC::Message const&) 0x0000007f664a355c (libchrome.so -message_filter_router.cc:22 ) TryFiltersImpl 0x0000007f66499ae0 (libchrome.so -ipc_channel_proxy.cc:87 ) IPC::ChannelProxy::Context::TryFilters(IPC::Message const&) 0x0000007f66499c8c (libchrome.so -ipc_channel_proxy.cc:122 ) IPC::ChannelProxy::Context::OnMessageReceived(IPC::Message const&) 0x0000007f66496efc (libchrome.so -ipc_channel_mojo.cc:414 ) IPC::ChannelMojo::OnMessageReceived(IPC::Message const&) 0x0000007f6649bf14 (libchrome.so -ipc_message_pipe_reader.cc:110 ) IPC::internal::MessagePipeReader::Receive(std::__ndk1::vector<unsigned char, std::__ndk1::allocator<unsigned char> > const&, base::Optional<std::__ndk1::vector<mojo::StructPtr<IPC::mojom::SerializedHandle>, std::__ndk1::allocator<mojo::StructPtr<IPC::mojom::SerializedHandle> > > >) 0x0000007f664a4ab4 (libchrome.so -ipc.mojom.cc:265 ) IPC::mojom::ChannelStubDispatch::Accept(IPC::mojom::Channel*, mojo::Message*) 0x0000007f6612da48 (libchrome.so -interface_endpoint_client.cc:408 ) mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*) 0x0000007f6612c400 (libchrome.so -filter_chain.cc:40 ) mojo::FilterChain::Accept(mojo::Message*) 0x0000007f6649e1e8 (libchrome.so -ipc_mojo_bootstrap.cc:755 ) Accept 0x0000007f6612c400 (libchrome.so -filter_chain.cc:40 ) mojo::FilterChain::Accept(mojo::Message*) 0x0000007f6612b958 (libchrome.so -connector.cc:387 ) mojo::Connector::ReadSingleMessage(unsigned int*) 0x0000007f6612bc08 (libchrome.so -connector.cc:416 ) mojo::Connector::ReadAllAvailableMessages() 0x0000007f6612ad74 (libchrome.so -bind_internal.h:214 ) Run 0x0000007f66135f88 (libchrome.so -callback.h:80 ) mojo::SimpleWatcher::OnHandleReady(int, unsigned int) 0x0000007f66136050 (libchrome.so -bind_internal.h:214 ) base::internal::Invoker<base::internal::BindState<void (content::ServiceWorkerProviderHost::*)(int, blink::WebServiceWorkerState), base::WeakPtr<content::ServiceWorkerProviderHost>, int, blink::WebServiceWorkerState>, void ()>::Run(base::internal::BindStateBase*) 0x0000007f6608f398 (libchrome.so -callback.h:91 ) base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) 0x0000007f660aa570 (libchrome.so -message_loop.cc:423 ) base::MessageLoop::RunTask(base::PendingTask*) 0x0000007f660aaea4 (libchrome.so -message_loop.cc:434 ) base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) 0x0000007f660ab31c (libchrome.so -message_loop.cc:527 ) base::MessageLoop::DoWork() 0x0000007f660ac8f4 (libchrome.so -message_pump_libevent.cc:219 ) base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) 0x0000007f660aa17c (libchrome.so -message_loop.cc:387 ) base::MessageLoop::RunHandler() 0x0000007f660c75a8 (libchrome.so -run_loop.cc:37 ) base::RunLoop::Run() 0x0000007f66d64a24 (libchrome.so -browser_thread_impl.cc:277 ) content::BrowserThreadImpl::IOThreadRun(base::RunLoop*) 0x0000007f66d64b24 (libchrome.so -browser_thread_impl.cc:312 ) content::BrowserThreadImpl::Run(base::RunLoop*) 0x0000007f660ee754 (libchrome.so -thread.cc:333 ) base::Thread::ThreadMain() 0x0000007f660e9524 (libchrome.so -platform_thread_posix.cc:71 ) ThreadFunc 0x0000007f9bdb5464 (libc.so + 0x00068464 ) This crash is first started from 59.0.3048.0 and observed the spike in recent dev build 59.0.3050.4 so far seeing 28 instances from 13 clients. Link to the list of builds =========================== https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Android%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer%20kill%2097%5D%20content%3A%3AResourceDispatcherHostImpl%3A%3ABeginRequest%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D 59.0.3050.4 - 28 59.0.3049.0 - 5 59.0.3048.0 - 1 Change log =========== https://chromium.googlesource.com/chromium/src/+log/59.0.3047.0..59.0.3048.0?pretty=fuller&n=10000 The Suspecting CL using file"resource_dispatcher_host_impl.cc" https://codereview.chromium.org/2758993002 Since this is a Recent regression, adding RB-Stable label ananta@ could you please look into this issue if it is related to your change, else please route this to an appropriate dev person. Thank You...
,
Mar 27 2017
Users experienced this crash on the following builds: Win Canary 59.0.3053.0 - 0.44 CPM, 2 reports, 2 clients (signature [Renderer kill 97] content::ResourceDispatcherHostImpl::BeginRequest) If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates. - Go/Fracas
,
Apr 3 2017
This is a PlzNavigate issue. Assigning to myself.
,
Apr 3 2017
,
Apr 4 2017
,
Apr 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/35be0078448bc5bc5198eac37562089682a555c1 commit 35be0078448bc5bc5198eac37562089682a555c1 Author: arthursonzogni <arthursonzogni@chromium.org> Date: Thu Apr 06 17:04:12 2017 PlzNavigate: add DumpWithoutCrashing for invalid main resource request. This CL is an attempt to solve https://crbug.com/705508 A DumpWithoutCrashing is added on the renderer side to get more informations. BUG= 705508 Review-Url: https://codereview.chromium.org/2805693002 Cr-Commit-Position: refs/heads/master@{#462517} [modify] https://crrev.com/35be0078448bc5bc5198eac37562089682a555c1/content/child/web_url_loader_impl.cc
,
Apr 11 2017
Just to update, not seeing any instances on Latest Market Dev# 59.0.3063.4. Seeing 20 instances on Latest Canary# 59.0.3067.0 as of now. Below is the link to list of builds -- https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Android%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer%20kill%2097%5D%20content%3A%3AResourceDispatcherHostImpl%3A%3ABeginRequest%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,+productversion:1000 Thank You.
,
Apr 11 2017
+mmenke and yhirano for questions about ResourceDispatcherHost. We're seeing this renderer kill when PlzNavigate is enabled (and with or without Mojo loading). This corresponds to a request for the main resource arriving from the renderer without a stream url associated with it, which should never happen in PlzNavigate. Arthur added a dump in his CL in comment 6, in WebURLLoaderImpl just before we ask the ResourceDispatcher to start the request (https://cs.chromium.org/chromium/src/content/child/web_url_loader_impl.cc?q=weburlloaderimpl&dr=CSs&l=640). But we're not seeing this hit in the field. We thought this was the only possibility to get a ResourceHostMsg_RequestResource IPC. Is there another path?
,
Apr 11 2017
Which ReceivedBadMessage call is this? The one about bad priorities or the is_navigation_stream_request one?
,
Apr 14 2017
#9: It is the is_navigation_stream_request one. (RDH_INVALID_URL)
,
Apr 14 2017
Does anything use a RenderViewHost without a WebContents? I assume extensions background pages have long since been removed, but I seem to remember some case where we were receiving requests from other processes (Not sure if it was renderer process or not) and crashing because they weren't associated with a frame, so we couldn't show auth dialogs.
,
Apr 18 2017
So we finally got hits of the Dump we added. We're wondering if we we're not seeing any until now because the renderer would be killed before sending the crash report? Links to the Dumps: https://crash.corp.google.com/browse?q=product.name%3D%22Chrome%22%20AND%20product.version%3D%2259.0.3067.6%22%20AND%20custom_data.ChromeCrashProto.channel%20IN%20(%22dev%22%2C%20%22dev-m%22)%20AND%20STRFTIME_USEC(reporttime*1000%2C%22%25Y%25m%25d%22)%3D%2220170416%22%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%22%5BDump%20without%20crash%5D%20content%3A%3AWebURLLoaderImpl%3A%3AContext%3A%3AStart%22%20OMIT%20RECORD%20IF%20SUM(custom_data.ChromeCrashProto.experiments.ids%3D%22c68ab9a3-6edc92c7%22)%20%3D%200&ignore_case=false&enable_rewrite=false&omit_field_name=&omit_field_value=&omit_field_opt=&stbtiq=&reportid=e470470e80000000&index=0 This seems to happen when creating a subframe, which attempts to request its main resource directly to the ResourceDispatcherHost instead of going through the browser navigation path.
,
Apr 19 2017
I also saw this report: ee93c28e80000000 The URL is http://sciencedirect.co.nf/science/article/pii/S0925231214524.htm The page contains a very interesting iframe that refers to a cid scheme: <iframe id="remote_iframe_0" name="remote_iframe_0" src="cid:frame-2004-fc23f851-96c0-45da-b132-ddfcce99fe4d@mhtml.blink" ...> It seems that any URL like scheme:something will trigger this.
,
Apr 19 2017
As I mentioned to some people CCed in this bug I received a warning from Finch-Chirp about the OfflinePageCache experiment having its Enabled group recording more crashes than its Control group, pointing out to the same crash signature from the OP. When I received the first alert and looked at the stack trace I assumed this was purely a PlzNavigate issue. But after receiving the 4th warning on 4/17th (crash link from the latest message [1]) I went back and looked into the count differences between the experiment groups [2]. Given the significant larger numbers for Enabled I begin to suspect there might be a bad interaction going on between PlzNavigate and Offline Pages and/or Offline Page Cache. However I am still unable to repro a crash that only happens when both features are enabled. The URL suggested above, for instance, needs only PlzNavigate to crash. PS: Removed Windows flag as this doesn't seem related to that OS. [1] https://crash.corp.google.com/browse?q=product.name%3D%22Chrome_Android%22%20AND%20product.version%3D%2259.0.3068.4%22%20AND%20custom_data.ChromeCrashProto.channel%20IN%20%28%22dev%22%29%20AND%20STRFTIME_USEC%28reporttime%2A1000%2C%22%25Y%25m%25d%22%29%3D%2220170416%22%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%22%5BRenderer%20kill%2097%5D%20content%3A%3AResourceDispatcherHostImpl%3A%3ABeginRequest%22%20OMIT%20RECORD%20IF%20SUM%28custom_data.ChromeCrashProto.experiments.ids%3D%224b52ecea-3f4a17df%22%29%20%3D%200 [2] https://uma.googleplex.com/p/chrome/variations/?sid=b8a634d76510a9bde5a143cf860b3cfa
,
Apr 19 2017
There is probably 2 kind of bug (or more). Thanks #13. I think I understand what the problem is. ShouldMakeNetworkRequestForURL(url) returns false for ContentID URLs (cid:...) url. But in the ressource fetcher: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp?q=ResourceFetcher.cpp+package:%5Echromium$&l=414 If the sub resource is not found in the MHTML archive, it falls back to do a network request. That is not expected by PlzNavigate. I will work on a fix.
,
Apr 19 2017
Issue 713146 has been merged into this issue.
,
Apr 19 2017
If the sub resource is not found in the MHTML archive, it will NOT fall back to do a network request. Please see comment here: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp?q=ResourceFetcher.cpp+package:%5Echromium$&l=584 Comment at line 414 probably needs to get updated. I think any kind of URL like foo:bar will trigger this.
,
Apr 19 2017
Also note that the URL in #13 is loaded as a normal web page, not a MHTML page.
,
Apr 19 2017
An issue with loading MHTML should explain the bad interaction I mentioned in #14. Offline Pages are saved as MHTML files and Offline Page Cache makes the loading of those MHTML files happen much more frequently.
,
Apr 20 2017
I found the two issues: 1) Request to a cid:xxxx url with no MHTMLArchive. Doing this will make the request going to the renderer-side-navigation path and triggers DCHECK/DumpWithoutCrashes. It can be easily fixed by aborting the navigation in that case. 2) Request to a normal url with an HTMLArchive. This doesn't work with PlzNavigate at all. All the tests passes but it is only because we were very lucky. This is what happens in the tests: - The request is caught by PlzNavigate in FrameLoader::ShouldContinueForNavigationPolicy - The navigation happens on the browser-side and a network request is sent. - The server answers by an HTML page "Not Found". - The request is committed on the renderer-side using a blob-url. - The response(as an blob-url request) is not caught in FrameLoader::ShouldContinueForNavigationPolicy - It enters in the ResourceFetcher - Then the resource is found in the MHTMLArchive and the "Not Found" page is replaced by the one that is in the archive. - The test passes...
,
Apr 20 2017
,
Apr 20 2017
,
Apr 20 2017
,
Apr 20 2017
,
Apr 29 2017
Users experienced this crash on the following builds: Mac Canary 60.0.3083.0 - 0.27 CPM, 1 reports, 1 clients (signature [Dump without crash] content::WebURLLoaderImpl::Context::Start) If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates. - Go/Fracas
,
May 5 2017
This crash has high impact on Chrome's stability. Signature: [Renderer kill 97] content::ResourceDispatcherHostImpl::BeginRequest. Channel: dev. Platform: android. Labeling issue 705508 with ReleaseBlock-Dev. If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates. - Go/Fracas
,
May 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8d745a7f38b559d75efe5b04a79f5fecd89a2e22 commit 8d745a7f38b559d75efe5b04a79f5fecd89a2e22 Author: arthursonzogni <arthursonzogni@chromium.org> Date: Mon May 08 19:47:57 2017 PlzNavigate: make MHTML iframe load working. This CL makes the renderer use the MHTML Archive when there is one for loading iframes. Some tests are added. Design doc: https://goo.gl/jCVFBc BUG= 705508 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_browser_side_navigation_rel Review-Url: https://codereview.chromium.org/2834013002 Cr-Commit-Position: refs/heads/master@{#470081} [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/content/common/navigation_params.cc [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/content/renderer/render_frame_impl.cc [add] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/LayoutTests/mhtml/cid_in_html_iframe-expected.txt [add] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/LayoutTests/mhtml/cid_in_html_iframe.html [add] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/LayoutTests/mhtml/cid_in_html_resource-expected.txt [add] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/LayoutTests/mhtml/cid_in_html_resource.html [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/Source/platform/mhtml/MHTMLArchive.h [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/Source/web/LocalFrameClientImpl.cpp [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/Source/web/LocalFrameClientImpl.h [modify] https://crrev.com/8d745a7f38b559d75efe5b04a79f5fecd89a2e22/third_party/WebKit/public/web/WebFrameClient.h
,
May 9 2017
Just to update, no instances of this crash is reported so far on beta build 59.0.3071.36. Below link gives in detail about the same: https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Android%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer%20kill%2097%5D%20content%3A%3AResourceDispatcherHostImpl%3A%3ABeginRequest%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000 P.S: This issue is tagged with M59 label and has a stable blocker with it. As the instances are not reported in current Beta, can this be considered as fixed on M59.? Thanks.!
,
May 9 2017
This bug only occurs when --enable-browser-side-navigation (aka PlzNavigate) is enabled. The PlzNavigate finch experiment is enabled only on Dev and Canary (for 50% of the users). That's why there is no instances reported in current Beta. I think I should remove the blocker flags. @ranjitkan: Please verify I am now using the right ones. I am not 100% sure how to use them, I worry about making a mistake. The previous CL should fix the bug (or at least one of them if there were several). It hasn't been tested on Canary yet.
,
May 10 2017
There are no more reports of this one for the current canary (60.0.3094.0). I will double check again tomorrow and close the bug as fixed if there are no more reports.
,
May 11 2017
There are still no occurrences of this crash on Android canary, so I will resolve it as fixed.
,
May 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f723e76be72fbbf475f4f0017a2191d986315428 commit f723e76be72fbbf475f4f0017a2191d986315428 Author: arthursonzogni <arthursonzogni@chromium.org> Date: Mon May 15 11:03:10 2017 PlzNavigate: make MHTML iframe working (followup) This is a followup to https://crrev.com/2834013002. It doesn't change the behavior of chrome but refactors some parts. BUG= 705508 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_browser_side_navigation_rel Review-Url: https://codereview.chromium.org/2871133002 Cr-Commit-Position: refs/heads/master@{#471722} [modify] https://crrev.com/f723e76be72fbbf475f4f0017a2191d986315428/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp [modify] https://crrev.com/f723e76be72fbbf475f4f0017a2191d986315428/third_party/WebKit/Source/web/LocalFrameClientImpl.cpp [modify] https://crrev.com/f723e76be72fbbf475f4f0017a2191d986315428/third_party/WebKit/Source/web/LocalFrameClientImpl.h
,
Jun 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fb9653132754cf5796f2aeb1c9b97b0b307acc53 commit fb9653132754cf5796f2aeb1c9b97b0b307acc53 Author: arthursonzogni <arthursonzogni@chromium.org> Date: Fri Jun 09 16:56:01 2017 PlzNavigate: Remove DumpWithoutCrashing() Since https://crbug.com/705508 is fixed, this DumpWithoutCrashing() can be removed. It was introduced in https://crrev.com/2805693002. BUG= 705508 R=clamy@chromium.org Review-Url: https://codereview.chromium.org/2915023002 Cr-Commit-Position: refs/heads/master@{#478310} [modify] https://crrev.com/fb9653132754cf5796f2aeb1c9b97b0b307acc53/content/child/web_url_loader_impl.cc
,
Jun 13 2017
Just to Update,
This crash is observed on latest canaries on Windows.
61.0.3128.0 1.36% 4 (Live for 24 hrs)
61.0.3127.0 0.34% 1
61.0.3126.0 0.34% 1
link to the list of "Windows" builds:
==========================
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer%20kill%2097%5D%20content%3A%3AResourceDispatcherHostImpl%3A%3ABeginRequest%27%20AND%20product.name%3D%27Chrome%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000
This crash is not observed on Android Since: 60.0.3101.4
Link to list of "Android" Builds:
=================================
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer%20kill%2097%5D%20content%3A%3AResourceDispatcherHostImpl%3A%3ABeginRequest%27%20AND%20product.name%3D%27Chrome_Android%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#-property-selector,samplereports:5,productversion:1000
arthursonzogni@ Could you please confirm the fix?
,
Jun 13 2017
Hi kkaluri, I am investigating. It is still a PlzNavigate(--enable-browser-side-navigation) only problem, but it is probably not the same bug this time.
,
Jun 13 2017
Users experienced this crash on the following builds: Win Canary 61.0.3128.0 - 0.20 CPM, 3 reports, 3 clients (signature [Renderer kill 97] content::ResourceDispatcherHostImpl::BeginRequest) If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates. - Go/Fracas
,
Jun 13 2017
I was able to find a repro. It looks like this bug is different. I opened a new bug: http://crbug.com/732780 I am closing the issue again.
,
Sep 1 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Mar 27 2017Labels: -Type-Bug Type-Bug-Regression
Owner: ananta@chromium.org