App crashes when signed into chrome with an Account having a Reading list entry which is already saved on device. |
||||
Issue descriptionApp Version: 57.0.2951.0 Canary iOS Version: 10.1.1 Device: iPad URL: Any URL ex : m.facebook.com Precondition: 1. Go to iOS settings --> Chrome Canary --> Experimental Settings --> Reading List : ON 2. Have a Reading list entry stored in Account A, ex : m.facebook.com Steps to reproduce: 1. Launch chrome. 2. Open any URL : m.facebook.com --> Save to “Reading List” 3. Go Menu --> Settings --> Sign into chrome with an account A. Observed results: App crashes. Crash Log : https://crash.corp.google.com/browse?stbtiq=6bf167ff00000000 Expected results: App should not crash Number of times you were able to reproduce: 5/5 Bug reproducible after clean install: Yes Bug reproducible after clearing cache and cookies: Yes Bug reproducible on Chrome Mobile on Android: NA Bug reproducible on Safari/Firefox: Firefox: NA, Safari: NA Bug reproducible on current stable build (App Version, iOS Version): New feature on M57 Bug reproducible on the current beta channel build (App Version, iOS Version): New feature on M57 Link to video/image: Video 1 : https://drive.google.com/a/google.com/file/d/0Bz2uwV55gGwDWURUdXJPWGJIcU0/view?usp=sharing Video 2: https://drive.google.com/a/google.com/file/d/0Bz2uwV55gGwDSldaNkQ0UnIyU3c/view?usp=sharing STACK TRACE : Thread 0 CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0x00000018 ] MAGIC SIGNATURE THREAD Stack Quality81%Show frame trust levels 0x0000000100ae05b4 (Chrome -gurl.cc:176 ) GURL::spec() const 0x00000001000c80ac (Chrome -reading_list_store.cc:238 ) ReadingListStore::MergeSyncData(std::__1::unique_ptr<syncer::MetadataChangeList, std::__1::default_delete<syncer::MetadataChangeList> >, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, syncer::ProtoValuePtr<syncer::EntityData, syncer::EntityDataTraits>, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, syncer::ProtoValuePtr<syncer::EntityData, syncer::EntityDataTraits> > > >) 0x0000000100bb4e6c (Chrome -shared_model_type_processor.cc:549 ) syncer::SharedModelTypeProcessor::OnInitialUpdateReceived(sync_pb::ModelTypeState const&, std::__1::vector<syncer::UpdateResponseData, std::__1::allocator<syncer::UpdateResponseData> > const&) 0x00000001005deb1c (Chrome -callback.h:68 ) base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) 0x00000001005f3eec (Chrome -message_loop.cc:413 ) base::MessageLoop::RunTask(base::PendingTask*) 0x00000001005f4134 (Chrome -message_loop.cc:422 ) base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) 0x00000001005f43f4 (Chrome -message_loop.cc:515 ) base::MessageLoop::DoWork() 0x0000000100642b74 (Chrome -message_pump_mac.mm:302 ) base::MessagePumpCFRunLoopBase::RunWork() 0x00000001006425b4 (Chrome -message_pump_mac.mm:278 ) base::MessagePumpCFRunLoopBase::RunWorkSource(void*) 0x000000018c598274 (CoreFoundation + 0x000dd274 ) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 0x000000018c597bbc (CoreFoundation + 0x000dcbbc ) __CFRunLoopDoSources0 0x000000018c5957bc (CoreFoundation + 0x000da7bc ) __CFRunLoopRun 0x000000018c4c4044 (CoreFoundation + 0x00009044 ) CFRunLoopRunSpecific 0x000000018df4a194 (GraphicsServices + 0x0000c194 ) GSEventRunModal 0x00000001924a92f8 (UIKit + 0x0007b2f8 ) -[UIApplication _run] 0x00000001924a4030 (UIKit + 0x00076030 ) UIApplicationMain 0x000000010000fe48 (Chrome -chrome_exe_main.mm:66 ) main 0x000000018b4a85b4 (libdyld.dylib + 0x000045b4 ) start
,
Dec 16 2016
That's really bad. Thanks for reporting.
,
Dec 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9c83edb6f6103807e3a98dc4052e2867f1775b54 commit 9c83edb6f6103807e3a98dc4052e2867f1775b54 Author: olivierrobin <olivierrobin@chromium.org> Date: Fri Dec 16 09:01:03 2016 Fix crash on mergeSync BUG= 674133 Review-Url: https://codereview.chromium.org/2583823002 Cr-Commit-Position: refs/heads/master@{#439071} [modify] https://crrev.com/9c83edb6f6103807e3a98dc4052e2867f1775b54/components/reading_list/ios/reading_list_store.cc
,
Dec 16 2016
,
Dec 17 2016
Has the fix been picked up in Canary? I am now seeing the same behaviour for both Dev and the latest Canary. If I delete my reading list, it doesn't crash.
,
Dec 17 2016
Do you have a crash report? It should be in the canary, but with the upstream compiler problem, I am not really sure. May be it is another problem.
,
Dec 17 2016
Here is the latest report : 7dfa941300000000 Attached a screenshot of chrome://crashes
,
Dec 17 2016
As mentionned in the other bug, 2952 is Thursday or Friday build and it does not contain the fix. Can you try the latest build (2954)?
,
Dec 17 2016
Thanks Olivier. What is on dogfoody is 2952 still. Let's wait :).
,
Jan 10 2017
Verified in 57.0.2977.0 canary, iPad mini 10.1 Followed steps from comment #0. No crash seeing, looks good. |
||||
►
Sign in to add a comment |
||||
Comment 1 by justincohen@chromium.org
, Dec 14 2016Labels: ReleaseBlock-Stable M-57
Owner: olivierrobin@chromium.org
Status: Assigned (was: Untriaged)