Manual bisect info:
Good build:57.0.2944.0
Bad build:57.0.2945.3

Note: Issue is not seen on Windows and Linux OS.

Deleted: Actual_welcome.mov 11.4 MB

Actual_welcome.mov 11.4 MB Download

Considering above as the changelog:
===================================
https://chromium.googlesource.com/chromium/src/+log/57.0.2944.0..57.0.2945.0?pretty=fuller&n=10000

Stack trace:
============
Thread 0 CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0x0000617ffffffff8 ] MAGIC SIGNATURE THREAD
Stack Quality78%Show frame trust levels
0x0000000110865d70	(Google Chrome Framework -memory:2594 )	std::__1::vector<std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> >, std::__1::allocator<std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> > > >::insert(std::__1::__wrap_iter<std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> > const*>, std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> >&&)
0x00000001108666f1	(Google Chrome Framework -tab_strip_model.cc:1307 )	TabStripModel::MoveWebContentsAtImpl(int, int, bool)
0x00000001109c8832	(Google Chrome Framework -browser_window_controller.mm:1113 )	-[BrowserWindowController moveTabViews:fromController:]
0x0000000110a75817	(Google Chrome Framework -tab_strip_drag_controller.mm:440 )	-[TabStripDragController endDrag:]
0x0000000110a74120	(Google Chrome Framework -tab_strip_drag_controller.mm:138 )	-[TabStripDragController maybeStartDrag:forTab:]
0x0000000110a7811b	(Google Chrome Framework -tab_view.mm:341 )	-[TabView mouseDown:]
0x00007fff8f2d96f2	(AppKit + 0x008be6f2 )	-[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:]
0x00007fff8f2d5f0f	(AppKit + 0x008baf0f )	-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:]
0x00007fff8f2d53ad	(AppKit + 0x008ba3ad )	-[NSWindow(NSEventRouting) sendEvent:]
0x00000001109d714e	(Google Chrome Framework -chrome_event_processing_window.mm:72 )	-[ChromeEventProcessingWindow sendEvent:]
0x00007fff8f1754cc	(AppKit + 0x0075a4cc )	-[NSApplication(NSEvent) sendEvent:]
0x000000010df5bbeb	(Google Chrome Framework -chrome_browser_application_mac.mm:275 )	__34-[BrowserCrApplication sendEvent:]_block_invoke
0x000000010e39b479	(Google Chrome Framework + 0x01914479 )	base::mac::CallWithEHFrame(void () block_pointer)
0x000000010df5baea	(Google Chrome Framework -chrome_browser_application_mac.mm:259 )	-[BrowserCrApplication sendEvent:]
0x00007fff8ea56588	(AppKit + 0x0003b588 )	-[NSApplication run]
0x000000010e3a9afd	(Google Chrome Framework -message_pump_mac.mm:637 )	base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*)
0x000000010e3a915b	(Google Chrome Framework -message_pump_mac.mm:210 )	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x000000010e3c71d2	(Google Chrome Framework -run_loop.cc:35 )	base::RunLoop::Run()
0x000000010df60c78	(Google Chrome Framework -chrome_browser_main.cc:1983 )	ChromeBrowserMainParts::MainMessageLoopRun(int*)
0x000000010d75f6b3	(Google Chrome Framework -browser_main_loop.cc:996 )	content::BrowserMainLoop::RunMainMessageLoopParts()
0x000000010d761d71	(Google Chrome Framework -browser_main_runner.cc:141 )	content::BrowserMainRunnerImpl::Run()
0x000000010d75b7fb	(Google Chrome Framework -browser_main.cc:46 )	content::BrowserMain(content::MainFunctionParams const&)
0x000000010df17d9f	(Google Chrome Framework -content_main_runner.cc:786 )	content::ContentMainRunnerImpl::Run()
0x000000010df17085	(Google Chrome Framework -content_main.cc:20 )	content::ContentMain(content::ContentMainParams const&)
0x000000010ca89e4b	(Google Chrome Framework -chrome_main.cc:100 )	ChromeMain
0x00000001088ced99	(Google Chrome Canary + 0x00000d99 )	
0x00007fffa5ea5254	(libdyld.dylib + 0x00005254 )	start

Based on the code search on 'tab_strip_drag_controller.mm' suspecting: https://codereview.chromium.org/2541653002.

njagsarran@: Could you please take a look at these crashes.

Thank you!

13 instances of this crash is observed currently on MAC from different client ID's and spike is seen in build 57.0.2945.3. Below link gives in detail about the same:

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%27TabStripModel%3A%3AMoveWebContentsAtImpl%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D

This crash is listed in top 10 browser crashes ranking 1 when reported. Adding blocker label, please undo if not the case.

Note: Hard to reproduce using the test case provided.

Thanks.!

Reproduced the same crashing stack locally, but with different repro steps:

1) Mouse down on a tab
2) Move the mouse up and down a few pixels - not enough to tear the tab off
3) Mouse up over the same tab

That causes crashes like 2b1174bf00000000.

I believe this is caused by https://codereview.chromium.org/2541653002/:

In [TabStripDragController continueDrag:], tabWasDragged_ is still set to YES even if the tab drag is not done because of the newly-introduced horizontal dead zone. Then, in [TabStripDragController endDrag:], the expected target placeholder tab is missing, but tabWasDragged_ is still YES, so [dropController moveTabViews:fromController:] causes a fatality.

On this basis, I'm going to revert CL 2541653002 and assign this bug to the author.

Revert in CQ: https://codereview.chromium.org/2557343002/

 Issue 672498  has been merged into this issue.

Users experienced this crash on the following builds:

Mac Canary 57.0.2945.3 -  237.27 CPM, 141 reports, 127 clients (signature TabStripModel::MoveWebContentsAtImpl)

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

- Go/Fracas

Issue 672610 has been merged into this issue.

The respective change (https://codereview.chromium.org/2557343002/) has already been reverted.

We were wondering why we saw a bunch of crashes with this stack on thread 0 but something else showing up as the crash thread. go/crash/460c16bf00000000 is an example, which showed up with

Thread 42 CRASHED [EXC_BAD_ACCESS / EXC_I386_GPFLT @ 0x00007fff9ce0014f ] MAGIC SIGNATURE THREAD
0x00007fff9ce0014f	(libobjc.A.dylib + 0x0001d14f )	std::__1::__hash_iterator<std::__1::__hash_node<std::__1::__hash_value_type<unsigned long, objc_references_support::ObjectAssociationMap*>, void*>*> std::__1::__hash_table<std::__1::__hash_value_type<unsigned long, objc_references_support::ObjectAssociationMap*>, std::__1::__unordered_map_hasher<unsigned long, std::__1::__hash_value_type<unsigned long, objc_references_support::ObjectAssociationMap*>, objc_references_support::DisguisedPointerHash, true>, std::__1::__unordered_map_equal<unsigned long, std::__1::__hash_value_type<unsigned long, objc_references_support::ObjectAssociationMap*>, objc_references_support::DisguisedPointerEqual, true>, objc_references_support::ObjcAllocator<std::__1::__hash_value_type<unsigned long, objc_references_support::ObjectAssociationMap*> > >::find<unsigned long>(unsigned long const&)
0x00007fff9cdec1aa	(libobjc.A.dylib + 0x000091aa )	_object_remove_assocations
0x00007fff9cdec0d2	(libobjc.A.dylib + 0x000090d2 )	objc_destructInstance
0x00007fff9cdec058	(libobjc.A.dylib + 0x00009058 )	object_dispose
0x000000010b261189	(Google Chrome Framework -objc_zombie.mm:158 )	(anonymous namespace)::ZombieDealloc(objc_object*, objc_selector*)
0x00007fff9d6a077f	(libdispatch.dylib + 0x0000277f )	-[OS_dispatch_data dealloc]
0x00007fff9cdf1db6	(libobjc.A.dylib + 0x0000edb6 )	objc_object::sidetable_release(bool)
0x00007fff9d92e4f8	(libxpc.dylib + 0x000044f8 )	_xpc_dispose
[…]

where thread 0 is
	0x000000010ccebd7e	(Google Chrome Framework -memory:2601 )	std::__1::vector<std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> >, std::__1::allocator<std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> > > >::insert(std::__1::__wrap_iter<std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> > const*>, std::__1::unique_ptr<TabStripModel::WebContentsData, std::__1::default_delete<TabStripModel::WebContentsData> >&&)
0x000000010ccec6f1	(Google Chrome Framework -tab_strip_model.cc:1307 )	TabStripModel::MoveWebContentsAtImpl(int, int, bool)
0x000000010ce4e832	(Google Chrome Framework -browser_window_controller.mm:1113 )	-[BrowserWindowController moveTabViews:fromController:]
0x000000010cefb817	(Google Chrome Framework -tab_strip_drag_controller.mm:440 )	-[TabStripDragController endDrag:]
0x000000010cefa120	(Google Chrome Framework -tab_strip_drag_controller.mm:138 )	-[TabStripDragController maybeStartDrag:forTab:]
0x000000010cefe11b	(Google Chrome Framework -tab_view.mm:341 )	-[TabView mouseDown:]

Thread 0 is actually culpable, despite not being the crash thread.

I believe that the std::vector<>::insert() in TabStripModel::MoveWebContentsAtImpl() is being given a bogus to_position out of the vector’s range. Crashes that occur on the crash thread show up as

Thread 0 CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0x000060fffffffff8 ] MAGIC SIGNATURE THREAD

EXC_BAD_ACCESS/KERN_INVALID_ADDRESS is consistent with being asked to operate on a vector out of bounds. For example:

#include <vector>

int main(int argc,char* argv[]) {
  std::vector<long> v;
  v.insert(v.end() + 1, 0);
  return 0;
}

is EXC_BAD_ACCESS/KERN_INVALID_ADDRESS (SIGSEGV). Sometimes. It depends on whether the memory is mapped where std::vector<>::insert() tries operating erroneously. If it is mapped, then it might be written to. And if it’s owned by something that’s running on another thread, then that other thread may crash when it tries to operate on data that’s been smashed by this bug. Crashes show up on another thread. If the vector decides that it needs to reallocate memory, you may wind up with malloc errors. A lot of crash signatures are possible at this point, especially in a multi-threaded program, and not all of them pinpoint the problem equally precisely.

 Issue 672513  has been merged into this issue.

Issue 672712 has been merged into this issue.

Above issue is seem to be fixed on Latest Chrome Version:57.0.2946.0 (Official Build) 38c3eb61c737a8d3313ca8cd31b0c514c9d35b05-refs/heads/master@{#437422} using MAC Retina (10.12.1)

Adding the verified label as per C#15 and crash data link as per C#3.

Issue 672595 has been merged into this issue.

Issue 672820 has been merged into this issue.

Issue 683639 has been merged into this issue.