Regression:Browser gets crashed on navigating to chrome://settings.
Reported by
shruti.j...@etouch.net,
May 10 2018
|
|||||||||||
Issue descriptionChrome Version: 68.0.3426.0 (Official Build) (64-bit)Revision ccd67e9feb61a58dd00a63b10cc08a36db957cba-refs/branch-heads/3426@{#1} OS: Linux(14.04 LTS) Steps to reproduce: 1.Launch chrome and navigate to chrome://settings 2.Observe. Actual Result: Browser gets crashed on navigating to chrome://settings. Expected Result: Browser should not get crashed on navigating to chrome://settings. Uploaded Crash Report ID 5aea64e29dae0e0d (Local Crash ID: Chrome) This is a regression issue broken in “M-68” and will soon update the other info: Good Build: 68.0.3425.0 Bad Build: 68.0.3426.0
,
May 10 2018
Windows canary 68.0.3426.0 has been live for 47 mins and this has reported 81 crashes from 75 clients. Considering below as the changelog: =================================== https://chromium.googlesource.com/chromium/src/+log/68.0.3425.0..68.0.3426.0?pretty=fuller&n=10000 dullweber@: Could these crashes be related to https://chromium-review.googlesource.com/c/chromium/src/+/1041956. If related, please revert the CL as this is top crash on the latest canary: 68.0.3426.0. shruti.jadhav@: Could you please update the per revision bisect to confirm if the suspected CL is same. Thank you!
,
May 10 2018
Stack trace of e1166511610d11d5: Thread 3 (id: 10488) CRASHED [EXCEPTION_ACCESS_VIOLATION_READ @ 0x00000000 ] MAGIC SIGNATURE THREAD Stack Quality83%Show frame trust levels 0x00007ffb00205520 (chrome.dll + 0x00015520 ) CBS_data 0x00007ffb01369b57 (chrome.dll -browsing_data_channel_id_helper.cc:89 ) `anonymous namespace'::BrowsingDataChannelIDHelperImpl::FetchOnIOThread 0x00007ffb00216024 (chrome.dll -task_annotator.cc:101 ) base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *) 0x00007ffb00215acb (chrome.dll -message_loop.cc:319 ) base::MessageLoop::RunTask(base::PendingTask *) 0x00007ffb00215517 (chrome.dll -message_loop.cc:373 ) base::MessageLoop::DoWork() 0x00007ffb0025fee9 (chrome.dll -message_pump_win.cc:478 ) base::MessagePumpForIO::DoRunLoop() 0x00007ffb0025fd77 (chrome.dll -message_pump_win.cc:56 ) base::MessagePumpWin::Run(base::MessagePump::Delegate *) 0x00007ffb00215090 (chrome.dll -run_loop.cc:131 ) base::RunLoop::Run() 0x00007ffb0025fce7 (chrome.dll -browser_process_sub_thread.cc:155 ) content::BrowserProcessSubThread::IOThreadRun(base::RunLoop *) 0x00007ffb002136c9 (chrome.dll -thread.cc:337 ) base::Thread::ThreadMain() 0x00007ffb013a7dc3 (chrome.dll -platform_thread_win.cc:91 ) base::`anonymous namespace'::ThreadFunc 0x00007ffb3d311fe3 (KERNEL32.DLL + 0x00011fe3 ) BaseThreadInitThunk 0x00007ffb3f0aef90 (ntdll.dll + 0x0006ef90 ) RtlUserThreadStart
,
May 10 2018
We have top Mac browser crash also with different magic signature but similar stack trace: Magic signature: net::ChannelIDService::GetChannelIDStore Stack trace: ============ Thread 7 (id: 2042105) CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0x00000000 ] MAGIC SIGNATURE THREAD Stack Quality83%Show frame trust levels 0x000000010a7e0684 (Google Chrome Framework -memory:2607 ) net::ChannelIDService::GetChannelIDStore() 0x000000010a02d5f8 (Google Chrome Framework -browsing_data_channel_id_helper.cc:91 ) (anonymous namespace)::BrowsingDataChannelIDHelperImpl::FetchOnIOThread(base::RepeatingCallback<void (std::__1::list<net::ChannelIDStore::ChannelID, std::__1::allocator<net::ChannelIDStore::ChannelID> > const&)> const&) 0x000000010a3fa3d6 (Google Chrome Framework -callback.h:96 ) base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) 0x000000010a41a8b3 (Google Chrome Framework -message_loop.cc:319 ) base::MessageLoop::RunTask(base::PendingTask*) 0x000000010a41ad87 (Google Chrome Framework -message_loop.cc:329 ) base::MessageLoop::DoWork() 0x000000010a4a9453 (Google Chrome Framework -message_pump_libevent.cc:210 ) base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) 0x000000010a43ef04 (Google Chrome Framework -run_loop.cc:131 ) <name omitted> 0x0000000108cbd813 (Google Chrome Framework -browser_process_sub_thread.cc:155 ) content::BrowserProcessSubThread::IOThreadRun(base::RunLoop*) 0x000000010a46fe2c (Google Chrome Framework -thread.cc:337 ) base::Thread::ThreadMain() 0x000000010a4a7c16 (Google Chrome Framework -platform_thread_posix.cc:76 ) base::(anonymous namespace)::ThreadFunc(void*) 0x00007fff59768660 (libsystem_pthread.dylib + 0x00003660 ) _pthread_body 0x00007fff5976850c (libsystem_pthread.dylib + 0x0000350c ) _pthread_start 0x00007fff59767bf8 (libsystem_pthread.dylib + 0x00002bf8 ) thread_start 0x000000010a4a7bbf (Google Chrome Framework + 0x02297bbf ) Based on the above stack trace https://chromium-review.googlesource.com/c/chromium/src/+/1050976 looks more plausible. Looks like suspected CL was reverted and then relanded again in Issue 841006 .
,
May 10 2018
Update: This is regression issue broken in ‘M-68’ and below is per-revision bisect result Good Build: 68.0.3425.0(Revision:557063) Bad Build: 68.0.3426.0(Revision:557428) CHANGE-LOG URL: https://chromium.googlesource.com/chromium/src/+log/b2939eb41644b2cd0e04dc340faa1e6734e5a066..7ebf529cfab66f217371f992eddfb5865e7884f4 Suspect: https://chromium.googlesource.com/chromium/src/+/7ebf529cfab66f217371f992eddfb5865e7884f4 @Nick : Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note : Issue is also reproducible on Windows(7,8,8.1,10) and Mac(10.12.6,10.13.1,10.13.5)
,
May 10 2018
Windows and Mac canary 68.0.3426.0 is supercrashy and there are muliple magic signature variants seen hence raising the priority to P0. We need to get the suspected CL reverted https://chromium-review.googlesource.com/c/chromium/src/+/1050976.
,
May 10 2018
I have https://chromium-review.googlesource.com/c/chromium/src/+/1053787 in progress to fix the crash.
,
May 10 2018
This has killed my canary install dead - the browser is dying immediately on launch. Win10 68.0.3426.1.
,
May 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4eeac8b64cdc37bf400867a4527f65392191cef3 commit 4eeac8b64cdc37bf400867a4527f65392191cef3 Author: Nick Harper <nharper@chromium.org> Date: Thu May 10 13:28:05 2018 Fix crash in BrowsingDataChannelIDHelperImpl when there's no ChannelIDService Bug: 841685 Change-Id: I1deb65b345058cf9317122ffb5bb4a236dd5446c Reviewed-on: https://chromium-review.googlesource.com/1053787 Commit-Queue: Nick Harper <nharper@chromium.org> Commit-Queue: Bernhard Bauer <bauerb@chromium.org> Reviewed-by: Bernhard Bauer <bauerb@chromium.org> Cr-Commit-Position: refs/heads/master@{#557501} [modify] https://crrev.com/4eeac8b64cdc37bf400867a4527f65392191cef3/chrome/browser/browsing_data/browsing_data_channel_id_helper.cc
,
May 10 2018
Issue 841752 has been merged into this issue.
,
May 10 2018
Issue 841711 has been merged into this issue.
,
May 10 2018
Issue 841703 has been merged into this issue.
,
May 10 2018
Issue 841753 has been merged into this issue.
,
May 10 2018
Issue 841767 has been merged into this issue.
,
May 10 2018
https://bugs.chromium.org/p/chromium/issues/detail?id=841278 covers a similar case where a net::ChannelIDService::GetChannelIDStore() call in NetworkContext has started failing with null dereference. I assume it's related? Should I add similar logic to check service not null there too, or were you planning a comprehensive fix?
,
May 10 2018
,
May 10 2018
With Channel ID being deprecated, we'll need null checks probably everywhere that gets a ChannelIDService from an URLRequestContext (assuming that a null ChannelIDService* won't be passed into methods expecting a ChannelIDService*). I don't have a comprehensive plan for finding all of them. (I was hoping the CQ would have enough coverage to find all the places that need checks added.)
,
May 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/23f21bbbf2dc0bf0f7a92d72ada153803c3f89a2 commit 23f21bbbf2dc0bf0f7a92d72ada153803c3f89a2 Author: Nick Harper <nharper@chromium.org> Date: Thu May 10 16:24:58 2018 Fix crash in BrowsingDataChannelIDHelperImpl when there's no ChannelIDService Bug: 841685 Change-Id: I1deb65b345058cf9317122ffb5bb4a236dd5446c Reviewed-on: https://chromium-review.googlesource.com/1053787 Commit-Queue: Nick Harper <nharper@chromium.org> Commit-Queue: Bernhard Bauer <bauerb@chromium.org> Reviewed-by: Bernhard Bauer <bauerb@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#557501}(cherry picked from commit 4eeac8b64cdc37bf400867a4527f65392191cef3) Reviewed-on: https://chromium-review.googlesource.com/1054109 Reviewed-by: Abdul Syed <abdulsyed@google.com> Cr-Commit-Position: refs/branch-heads/3426@{#3} Cr-Branched-From: 2a324b4c3ab068ca99b5dead0b2a336a4776befb-refs/heads/master@{#557428} [modify] https://crrev.com/23f21bbbf2dc0bf0f7a92d72ada153803c3f89a2/chrome/browser/browsing_data/browsing_data_channel_id_helper.cc
,
May 10 2018
Issue 841870 has been merged into this issue.
,
May 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1772494e8fe6ed97c03577a1dde99bf4527bad76 commit 1772494e8fe6ed97c03577a1dde99bf4527bad76 Author: Nick Harper <nharper@chromium.org> Date: Thu May 10 19:52:55 2018 Enable Channel ID Too many places throughout the codebase assumed that an URLRequestContext would have a (non-null) ChannelIDService. When the base::Feature kChannelID is disabled, this results in a null ChannelIDService on the URLRequestContext, and results in crashes due to null derefs. Bug: 841730 , 841685 Change-Id: Iece0f584d7c05e90ea16da2ea9319b66768ded33 Reviewed-on: https://chromium-review.googlesource.com/1054177 Reviewed-by: Ryan Hamilton <rch@chromium.org> Commit-Queue: Nick Harper <nharper@chromium.org> Cr-Commit-Position: refs/heads/master@{#557635} [modify] https://crrev.com/1772494e8fe6ed97c03577a1dde99bf4527bad76/components/network_session_configurator/common/network_features.cc
,
May 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8c1c93db7c47aa39b55b4c3119ee481308b88422 commit 8c1c93db7c47aa39b55b4c3119ee481308b88422 Author: Nick Harper <nharper@chromium.org> Date: Thu May 10 20:50:38 2018 Enable Channel ID Too many places throughout the codebase assumed that an URLRequestContext would have a (non-null) ChannelIDService. When the base::Feature kChannelID is disabled, this results in a null ChannelIDService on the URLRequestContext, and results in crashes due to null derefs. Bug: 841730 , 841685 Change-Id: Iece0f584d7c05e90ea16da2ea9319b66768ded33 Reviewed-on: https://chromium-review.googlesource.com/1054177 Reviewed-by: Ryan Hamilton <rch@chromium.org> Commit-Queue: Nick Harper <nharper@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#557635}(cherry picked from commit 1772494e8fe6ed97c03577a1dde99bf4527bad76) Reviewed-on: https://chromium-review.googlesource.com/1054353 Reviewed-by: Abdul Syed <abdulsyed@google.com> Cr-Commit-Position: refs/branch-heads/3426@{#4} Cr-Branched-From: 2a324b4c3ab068ca99b5dead0b2a336a4776befb-refs/heads/master@{#557428} [modify] https://crrev.com/8c1c93db7c47aa39b55b4c3119ee481308b88422/components/network_session_configurator/common/network_features.cc
,
May 10 2018
,
May 10 2018
,
May 11 2018
(stability sheriff) looks like fixes landed or are landing?
,
May 11 2018
Please also check the coherence of this error with browser sync (login to Chrome) - I got the message that syncing is disabled with request to adjust settings, and when I navigate to settings, the browser immediately crashes. Thanks!
,
May 11 2018
,
May 11 2018
Update : Retested above issue on Windows (7,8,8.1,10) Linux(14.04 LTS) and Mac(10.12.6,10.13.1,10.13.5) OS using latest Canary #68.0.3427.0 and issue is fixed.Browser does not get crashed on navigating chrome://settings.Kindly review the attached screen-cast. Thank you!
,
May 11 2018
Is there a reasonable browser test that we can add that would catch this type of error in the future?
,
May 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/141dfc707916f5db1db551fd2710e278aaf9e8bc commit 141dfc707916f5db1db551fd2710e278aaf9e8bc Author: Nick Harper <nharper@chromium.org> Date: Fri May 11 19:04:18 2018 Don't restrict creation of ChannelIDService to only when features::kChannelID is enabled This is a revert of http://crrev.com/1e5757d just for the two files here. Bug: 841685 Change-Id: I4d6b211d45e2b2104b440daa8c8f6715fb6c5ab2 Reviewed-on: https://chromium-review.googlesource.com/1055678 Reviewed-by: Ryan Hamilton <rch@chromium.org> Commit-Queue: Nick Harper <nharper@chromium.org> Cr-Commit-Position: refs/heads/master@{#557967} [modify] https://crrev.com/141dfc707916f5db1db551fd2710e278aaf9e8bc/chrome/browser/net/profile_network_context_service.cc [modify] https://crrev.com/141dfc707916f5db1db551fd2710e278aaf9e8bc/chrome/browser/profiles/profile_impl_io_data.cc
,
May 14 2018
Update : Retested above issue on Windows (7,8,8.1,10) Linux(14.04 LTS) and Mac(10.12.6,10.13.1,10.13.5) OS using latest Canary #68.0.3430.0 and issue is fixed. Browser does not get crashed on navigating chrome://settings .Kindly review the attached screen-cast. Thank you!
,
May 14 2018
As mentioned in comment 28, having a browser test that would have caught this would be nice to have, but I don't know what said test would look like. Maybe just a smoke test that opens chrome://settings would be enough?
,
Jun 8 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by vsemozhe...@gmail.com
, May 10 2018