#2 browser crash in 5.0.307.1

Sky, is it related to phantom tab changes? 

Call stack

0x01cfced7	 [chrome.dll	 - logging.cc:587]	
logging::LogMessage::~LogMessage()
0x01dc7e97	 [chrome.dll	 - tab_strip_model.cc:778]	
TabStripModel::GetContentsAt(int)
0x01dc7b94	 [chrome.dll	 - tab_strip_model.cc:714]	
TabStripModel::InternalCloseTabs(std::vector<int,std::allocator<int> >,bool)
0x01d60d87	 [chrome.dll	 - browser.h:247]	Browser::CloseAllTabs()
0x01d61cab	 [chrome.dll	 - browser.cc:568]	Browser::OnWindowClosing()
0x01d65920	 [chrome.dll	 - browser.cc:2850]	Browser::ProcessPendingTabs()
0x01d65a6c	 [chrome.dll	 - browser.cc:2919]	
Browser::ClearUnloadState(TabContents *)
0x01d64592	 [chrome.dll	 - browser.cc:2067]	
Browser::CloseContents(TabContents *)
0x01d6ff7e	 [chrome.dll	 - tab_contents.cc:2226]	
TabContents::Close(RenderViewHost *)
0x01dd3034	 [chrome.dll	 - render_view_host.cc:345]	
RenderViewHost::ClosePageIgnoringUnloadEvents()
0x01d9f291	 [chrome.dll	 - resource_dispatcher_host.cc:128]	`anonymous 
namespace'::RVHCloseNotificationTask::Run()
0x01cf4917	 [chrome.dll	 - message_loop.cc:320]	MessageLoop::RunTask(Task *)
0x01cf4951	 [chrome.dll	 - message_loop.cc:328]	
MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)
0x01cf4b06	 [chrome.dll	 - message_loop.cc:435]	MessageLoop::DoWork()
0x01d063a7	 [chrome.dll	 - message_pump_win.cc:209]	
base::MessagePumpForUI::DoRunLoop()
0x01d061bc	 [chrome.dll	 - message_pump_win.cc:52]	
base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate 
*,base::MessagePumpWin::Dispatcher *)
0x01cf47bc	 [chrome.dll	 - message_loop.cc:200]	MessageLoop::RunInternal()
0x01cf474c	 [chrome.dll	 - message_loop.cc:177]	MessageLoop::RunHandler()
0x01cf4d00	 [chrome.dll	 - message_loop.cc:603]	
MessageLoopForUI::Run(base::MessagePumpWin::Dispatcher *)
0x01d461b2	 [chrome.dll	 - browser_main.cc:161]	`anonymous 
namespace'::RunUIMessageLoop(BrowserProcess *)
0x01d4782b	 [chrome.dll	 - browser_main.cc:993]	
BrowserMain(MainFunctionParams const &)
0x01c33a90	 [chrome.dll	 - chrome_dll_main.cc:749]	ChromeMain
0x00403142	 [chrome.exe	 - client_util.cc:176]	
MainDllLoader::Launch(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *)
0x00403810	 [chrome.exe	 - chrome_exe_main.cc:48]	wWinMain
0x00427c53	 [chrome.exe	 - crt0.c:324]	__tmainCRTStartup
0x7c817066	 [kernel32.dll	 + 0x00017066]	BaseProcessStart

(No comment was entered for this change.)

I see the bug. It'll temporarily go away as I've effectively disabled pinned tabs. 
None-the-less I'll fix the real issue here.

Actually I'm wrong. I don't see this being related to phantom tabs, but I'll keep 
poking at it.

Is this dup of  issue 34137  as well?

No, this crash looks different.

(No comment was entered for this change.)

This is the #1 TopCrash on Mac 5.0.396.0 
http://crash/reportdetail?reportid=fa4c3fdf539bd5db

getting on m5 radar since it's a top crash.

I thought 375 was M5 and > 375 is M6.

I don't see this crash in 375 or 396 on windows. I'm marking available.

(No comment was entered for this change.)

(No comment was entered for this change.)

This is the top Mac crash in 5.0.396.0 (current dev release). In that version, the CHECK failure happens at tab_strip_model.cc:866. Here we are:

864  TabContents* TabStripModel::GetContentsAt(int index) const {
865    CHECK(ContainsIndex(index)) <<
866        "Failed to find: " << index << " in: " << count() << " entries.";
867    return contents_data_.at(index)->contents;
868  }

Mark, do you have a full stack?

Mark is referring to  Issue 44454 , which is in the same general code for the top few frames, but beyond that 
looks like it's related to downloads (so may be same root cause, but seems reasonable to leave them separate 
until someone looks closely).

Seems to be mac specific crasher, assigning to shess.

This is still happening on the stable/beta channel:
   http://crash/reportdetail?reportid=69ffc5e3e8ad26a9
it's also still happening on the dev channel, though the volume isn't huge.  This might just be because the dev channel doesn't have a lot of users.  The crashes don't really aggregate, so it doesn't show on the front page...

Trung, you understand the shutdown code, right?  For some reason I find myself thinking about your points about close sometimes doing the wrong thing.  There are cases where it's in OnWindowClosing() and CloseAllTabs(), which makes me wonder.

FYI, the problem in  issue 44454  was that TabService::InternalCloseTabs calls Browser::CanCloseContentsAt, which could already close a tab (from what I gathered, it tried to bring up the "Are you sure you want to quit?" dialog by closing the window, but dialog didn't show up, so the window simply got closed). Then it would try to close the tab with the same index again, which of course didn't exist anymore. 

(No comment was entered for this change.)

@pinkerton: I think andybons may have fixed this, but since we don't have a repro, I guess we need to check the crash server to verify.

@vtl, what bug was andy fixing when he "may have fixed this"?

Oops, I take that back. I misunderstood what happened, but was thinking of http://crrev.com/52394 . In any case, it looks to me like TabStripModel::InternalCloseTabs() is missing a null check after its call to GetContentsAt().

Though now that I look more closely, if GetContentsAt() is allowed to return NULL (for a "closed" pinned tab?), then there may be many other broken calls to it too. Hrm.

> if GetContentsAt() is allowed to return NULL (for a "closed" pinned tab?)

Phantom tabs still have tabcontents. They just have no renderer.

(No comment was entered for this change.)

I don't see this anywhere in our crash data for 6.0.472.X.

Can someone find a crash dump that has it?

Pulling releaseblock based on Mike's comment.

(No comment was entered for this change.)

If this is no longer showing up, I'm going to close it. Please re-open if it shows up again in our crash logs.

Seeing it in 8.0.549.0.

http://crash/reportdetail?reportid=0a2696a04639e2f0

Thread 0 *CRASHED* ( EXCEPTION_BREAKPOINT @ 0x01d018b4 )

0x01d018b4	 [chrome.dll	 - debug_util_win.cc:225]	DebugUtil::BreakDebugger()
0x01cfde62	 [chrome.dll	 - logging.cc:656]	logging::LogMessage::~LogMessage()
0x01e7922c	 [chrome.dll	 - tab_strip_model.cc:874]	TabStripModel::GetContentsAt(int)
0x01e7906f	 [chrome.dll	 - tab_strip_model.cc:828]	TabStripModel::InternalCloseTabs(std::vector<int,std::allocator<int> > const &,unsigned int)
0x01dafec7	 [chrome.dll	 - browser.cc:861]	Browser::CloseAllTabs()
0x01dafe23	 [chrome.dll	 - browser.cc:810]	Browser::OnWindowClosing()
0x01db488e	 [chrome.dll	 - browser.cc:3725]	Browser::ProcessPendingTabs()
0x01db4a33	 [chrome.dll	 - browser.cc:3802]	Browser::ClearUnloadState(TabContents *)
0x01db3121	 [chrome.dll	 - browser.cc:2810]	Browser::CloseContents(TabContents *)
0x01dcbc21	 [chrome.dll	 - tab_contents.cc:2592]	TabContents::Close(RenderViewHost *)
0x01dffedd	 [chrome.dll	 - render_view_host.cc:363]	RenderViewHost::ClosePageIgnoringUnloadEvents()
0x01cf6a1f	 [chrome.dll	 - message_loop.cc:410]	MessageLoop::RunTask(Task *)
0x01cf6aab	 [chrome.dll	 - message_loop.cc:419]	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)
0x01cf6c45	 [chrome.dll	 - message_loop.cc:526]	MessageLoop::DoWork()
0x01d0bcff	 [chrome.dll	 - message_pump_win.cc:202]	base::MessagePumpForUI::DoRunLoop()
0x01d0bb0a	 [chrome.dll	 - message_pump_win.cc:51]	base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate *,base::MessagePumpWin::Dispatcher *)
0x01cf679c	 [chrome.dll	 - message_loop.cc:253]	MessageLoop::RunInternal()
0x01cf6725	 [chrome.dll	 - message_loop.cc:230]	MessageLoop::RunHandler()
0x01cf6e59	 [chrome.dll	 - message_loop.cc:656]	MessageLoopForUI::Run(base::MessagePumpWin::Dispatcher *)
0x01d78c82	 [chrome.dll	 - browser_main.cc:471]	`anonymous namespace'::RunUIMessageLoop(BrowserProcess *)
0x01d7a827	 [chrome.dll	 - browser_main.cc:1483]	BrowserMain(MainFunctionParams const &)
0x01c34011	 [chrome.dll	 - chrome_dll_main.cc:947]	ChromeMain
0x00403c64	 [chrome.exe	 - client_util.cc:247]	MainDllLoader::Launch(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *)
0x00404081	 [chrome.exe	 - chrome_exe_main.cc:46]	wWinMain

Any update on this? Continues to be a top browser crash on window canary (8.0.555.0).

For example: http://crash/reportdetail?reportid=5708162f878ed17d

I thought all crashes were mac related. The dump from Eric is obviously windows.

Still seeing this as a top-crash on latest windows canary (8.0.561.0).

For example: http://crash/reportdetail?reportid=0d827aaffc4a16eb

Still top windows browser crash on canary (9.0.574.0).

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=65872

------------------------------------------------------------------------
r65872 | sky@chromium.org | Thu Nov 11 15:04:54 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model_unittest.cc?r1=65872&r2=65871&pathrev=65872
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.cc?r1=65872&r2=65871&pathrev=65872

Fixes possible crash in TabStripModel. If during close all a tab was
removed out from under the TabStripModel it would still attempt to
remove the tab. At least this is my best guess as to what is causing
the crash.

BUG=34135
TEST=none

Review URL: http://codereview.chromium.org/4687009
------------------------------------------------------------------------

I took my best guess at what is causing this crash. If you see it in the next build, reopen.

Re-opening, as I am still seeing this in 10.0.628.0. For example:

http://crash/reportdetail?reportid=5d09d6b4a8c02e39

This crash in comment 38 is similar in that it is triggering the same check, but the rest of the stack is different from what I fixed. I'll see if I can figure out what is happening though.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=71116

------------------------------------------------------------------------
r71116 | sky@chromium.org | Tue Jan 11 16:29:03 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model_order_controller.cc?r1=71116&r2=71115&pathrev=71116
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.cc?r1=71116&r2=71115&pathrev=71116
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model_order_controller.h?r1=71116&r2=71115&pathrev=71116

Adds some debugging code in hopes of figuring out why we're
crashing. I can only see this crash happening if the opener ends up
equal to contents, but that doesn't seem possible in code.

BUG=34135
TEST=none

Review URL: http://codereview.chromium.org/6124009
------------------------------------------------------------------------

 Issue 69830  has been merged into this issue.

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=71800

------------------------------------------------------------------------
r71800 | sky@chromium.org | Wed Jan 19 08:22:46 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.cc?r1=71800&r2=71799&pathrev=71800
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.h?r1=71800&r2=71799&pathrev=71800

Attempt at fixing crash in tab code. It appears that we end up in a
situation where the opener ends up the same as the tab being
closed. The only way I could see this happening is a new tab getting
the same address as a tab that was deleted. This seems unlikely, but
I've added the code to make sure we clean up properly when a tab is
deleted. I'm also adding a couple more checks.

BUG=34135
TEST=none

Review URL: http://codereview.chromium.org/6346008
------------------------------------------------------------------------

The CHECKs I added to help isolate this is getting hit quite frequently. I'm tagging this bug as a beta blocker. If I cant find the real culprit, I should at least pull the CHECKs before beta so that we're no worse then we were before.

(No comment was entered for this change.)

I don't see the CHECKs getting hit in 10.0.644.0 or 10.0.645.0. It looks like my fix @71800 finally fixed it. I'll remove the CHECKs and other debugging code then move to fixed.

(No comment was entered for this change.)

Secseverity lowered due to tab control required (possible through extensions)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=72396

------------------------------------------------------------------------
r72396 | sky@chromium.org | Mon Jan 24 13:59:32 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model_order_controller.cc?r1=72396&r2=72395&pathrev=72396
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.cc?r1=72396&r2=72395&pathrev=72396
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model_order_controller.h?r1=72396&r2=72395&pathrev=72396

Removes debugging code as cause of crash was found.

I'm TBRing as this is just a removing of unneeded CHECKs.

BUG=34135
TEST=none
TBR=ben@chromium.org

Review URL: http://codereview.chromium.org/6291011
------------------------------------------------------------------------

(No comment was entered for this change.)

Need to merge this to m9.

Merged to M9 landed @73185.

@Sky, do we need to do a m10 merge for this at all ?

No. The CHECK is in M10, but so is the fix, so it shouldn't matter.

Awesome! thanks Scott. Sorry, just need to make sure that any milestone is not missed :)

Product: Chrome
Stack Signature: logging::LogMessage::~LogMessage()-65F334
New Signature Label: logging::LogMessage::~LogMessage()
New Signature Hash: ec14db02_c2ed741b_1509a5b5_85ea9f05_8a10a5d4

Report link: http://go/crash/reportdetail?reportid=e709af6860f0edd9

Meta information:
Product Name: Chrome
Product Version: 5.0.307.1
Report ID: e709af6860f0edd9
Report Time: 2010/01/31 02:16:19, Sun
Uptime: 7937 sec
Cumulative Uptime: 0 sec
OS Name: Windows NT
OS Version: 5.1.2600 Service Pack 3
CPU Architecture: x86
CPU Info: GenuineIntel family 6 model 13 stepping 8

(No comment was entered for this change.)

Batch update.

Batch update.

Batch update.

Lifting view restrictions.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)