New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 133108 link

Starred by 5 users

Issue metadata

Status: Verified
Owner:
Closed: Jun 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Chrome: Crash Report - Stack Signature: RaiseException-25abdca1_4703d1ca_6817671c_6...

Project Member Reported by kareng@google.com, Jun 15 2012

Issue description

Product: Chrome
Stack Signature: RaiseException-3C2FB4B
New Signature Label: RaiseException
New Signature Hash: 25abdca1_4703d1ca_6817671c_6ec64482_3de1cc4e

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

Meta information:
Product Name: Chrome
Product Version: 21.0.1175.0
Report ID: ba3f0167fb394cf0
Report Time: 2012/06/15 21:43:11, Fri
Uptime: 2620 sec
Cumulative Uptime: 0 sec
OS Name: Windows NT
OS Version: 6.1.7601 Service Pack 1
CPU Architecture: x86
CPU Info: AuthenticAMD family 16 model 6 stepping 2

Thread 0 *CRASHED* ( Unhandled C++ Exception @ 0x7533d36f )

0x7533d36f	 [KERNELBASE.dll]	 + 0x0000d36f]	RaiseException
0x628b5e36	 [chrome.dll]	 - throw.cpp:155]	_CxxThrowException
0x628b0a52	 [chrome.dll]	 - xthrow.cpp:18	std::_Xout_of_range(char const *)
0x612d64b4	 [chrome.dll]	 - xtree:1205]	std::_Tree<std::_Tmap_traits<Profile *,int,std::less<Profile *>,std::allocator<std::pair<Profile * const,int> >,0> >::erase(std::_Tree_const_iterator<std::_Tree_val<std::_Tmap_traits<Profile *,int,std::less<Profile *>,std::allocator<std::pair<Profile * const,int> >,0> > >)
0x620e5aa0	 [chrome.dll]	 - google_url_tracker.cc:253	GoogleURLTracker::InfoBarClosed(InfoBarTabHelper const *)
0x620e5dff	 [chrome.dll]	 - google_url_tracker.cc:145	GoogleURLTrackerInfoBarDelegate::~GoogleURLTrackerInfoBarDelegate()
0x620e5f0f	 [chrome.dll]	 + 0x00ea5f0f]	GoogleURLTrackerInfoBarDelegate::`vector deleting destructor'(unsigned int)
0x61747fe0	 [chrome.dll]	 - browser_accessibility.cc:210	IndexedDBDispatcher::OnWorkerRunLoopStopped()
0x616dc206	 [chrome.dll]	 - infobar.cc:186	InfoBar::MaybeDelete()
0x616dc135	 [chrome.dll]	 - infobar.cc:136	InfoBar::AnimationEnded(ui::Animation const *)
0x61662154	 [chrome.dll]	 - animation.cc:60	ui::Animation::Stop()
0x616c78ba	 [chrome.dll]	 - linear_animation.cc:79	ui::LinearAnimation::Step(base::TimeTicks)
0x616c77fd	 [chrome.dll]	 - animation_container.cc:76	ui::AnimationContainer::Run()
0x61290f79	 [chrome.dll]	 - timer.cc:181	base::Timer::RunScheduledTask()
0x7374270b	 [winmm.dll]	 + 0x0000270b]	timeGetTime
0x61290ee2	 [chrome.dll]	 - timer.cc:46	base::BaseTimerTaskInternal::Run()
0x6125d528	 [chrome.dll]	 - message_loop.cc:465	MessageLoop::RunTask(base::PendingTask const &)
0x6125bb8c	 [chrome.dll]	 - message_loop.cc:692	MessageLoop::DoDelayedWork(base::TimeTicks *)
0x61400589	 [chrome.dll]	 - message_pump_win.cc:244	base::MessagePumpForUI::DoRunLoop()
0x6125b5b5	 [chrome.dll]	 - message_loop.cc:419	MessageLoop::RunInternal()
0x6169c2e7	 [chrome.dll]	 - message_loop.cc:770	MessageLoopForUI::RunWithDispatcher(base::MessagePumpDispatcher *)
0x6169c12c	 [chrome.dll]	 - chrome_browser_main.cc:1903	ChromeBrowserMainParts::MainMessageLoopRun(int *)
0x6169c0d2	 [chrome.dll]	 - browser_main_loop.cc:440	content::BrowserMainLoop::RunMainMessageLoopParts()
0x6169c094	 [chrome.dll]	 - browser_main_runner.cc:98	`anonymous namespace'::BrowserMainRunnerImpl::Run()
0x612d76ce	 [chrome.dll]	 - browser_main.cc:21	BrowserMain(content::MainFunctionParams const &)
0x612578a5	 [chrome.dll]	 - content_main_runner.cc:371	content::RunNamedProcessTypeMain(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,content::MainFunctionParams const &,content::ContentMainDelegate *)
0x6125782c	 [chrome.dll]	 - content_main_runner.cc:626	content::ContentMainRunnerImpl::Run()
0x6124a241	 [chrome.dll]	 - content_main.cc:35	content::ContentMain(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *,content::ContentMainDelegate *)
0x6124a1cd	 [chrome.dll]	 - chrome_main.cc:28	ChromeMain
0x011c63ca	 [chrome.exe]	 - client_util.cc:423	MainDllLoader::Launch(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *)
0x011c55c6	 [chrome.exe]	 - chrome_exe_main_win.cc:31	RunChrome(HINSTANCE__ *)
0x011c5631	 [chrome.exe]	 - chrome_exe_main_win.cc:47	wWinMain
0x0121d992	 [chrome.exe]	 - crt0.c:275	__tmainCRTStartup
0x769ced6b	 [kernel32.dll]	 + 0x0004ed6b]	BaseThreadInitThunk
0x7715377a	 [ntdll.dll]	 + 0x0006377a]	__RtlUserThreadStart
0x7715374d	 [ntdll.dll]	 + 0x0006374d]	_RtlUserThreadStart

peter this is a top browser crash on canary, any chance you might have an idea what's going on?

 
Cc: kareng@google.com
I looked at the code for a while but can't figure out what could cause this.  Any chance we can get a regression range or repro steps?
Could this be the same as  bug 132615 ?
Cc: pkasting@chromium.org
 Issue 132615  has been merged into this issue.
Labels: Mstone-20
I believe this is a double-free of GoogleURLTrackerInfoBarDelegate.

Comment 5 by kareng@google.com, Jun 18 2012

is there a reason u marked it as M20 not M21? I see it in M21. Is it also in M20?
The duped-in  bug 132615  was M20.

Comment 7 by kareng@google.com, Jun 18 2012

oh i see :) thanks! 
Cc: stevet@chromium.org
Issue 134037 has been merged into this issue.
Project Member

Comment 9 by bugdroid1@chromium.org, Jun 26 2012

Summary: Chrome: Crash Report - Stack Signature: RaiseException-25abdca1_4703d1ca_6817671c_6...
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=144201

------------------------------------------------------------------------
r144201 | pkasting@chromium.org | Tue Jun 26 10:37:40 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/google/google_url_tracker_unittest.cc?r1=144201&r2=144200&pathrev=144201
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/google/google_url_tracker.h?r1=144201&r2=144200&pathrev=144201
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/google/google_url_tracker.cc?r1=144201&r2=144200&pathrev=144201

More comprehensive handling of NOTIFICATION_NAV_ENTRY_PENDING for GoogleURLTracker.

In particular, there are three cases that are improved:
(1) We didn't deal well with further searches in the same tab that was already showing an infobar.  Depending on ordering, various kinds of badness could occur, in particular trying to deref infobar_map_.end().
(2) If we caught a PENDING search, but before the load committed the user performed some other navigation, we'd show the infobar on the commit for the later navigation, leading to infobars on random pages.
(3) In a generalization of (2), we now listen for PENDING in many more cases so that we know if the user is starting a new navigation, which may be the only way we get signalled that a previous navigation has been cancelled.  (Note that if a pending navigation is simply stopped, and we were waiting for commit, we'll keep waiting, but this is harmless since eventually either the tab will be closed or the user will start another navigation.)

These changes should hopefully make GoogleURLTracker as robust about navigation-handling as AlternateNavURLFetcher already was.

Additionally, I reverted a previous change where a pending search would change the "search_url" of a visible infobar in that tab.  Because we don't get notified when a load is stopped, we can't distinguish between "started a new search that hasn't committed" and "started but then cancelled a new search", and thus it's potentially wrong to search for the new URL (yet).  We now once again wait until a search actually commits.  In doing this I simplified things so that we only even pass in the search URL when a load commits.

BUG= 133108 
TEST=Edit your preferences file so that you get prompted about changing Google search URLs.  Do a Google search in one tab, wait for the infobar to appear, then do another search in the same tab.  The infobar should stick around and interacting with it shouldn't cause crashes.
Review URL: https://chromiumcodereview.appspot.com/10630022
------------------------------------------------------------------------
Cc: dharani@chromium.org
Labels: -Mstone-20 Mstone-21 Merge-Requested
Status: Fixed
Fixed in r144201.

IMO this fix is too scary for M20 unless this is causing tons of crashes, so I'm changing this to be an M21 merge request.

Comment 11 by kareng@google.com, Jun 26 2012

do u feel it's relatively safe for m21? i can track how big the crash is there before we decide to merge or not.
M21 is far enough off that I'm OK with merging this, but if you want we can try to watch the crash stats beforehand.  It might be tricky to get comprehensive stats since this could manifest in a variety of different stacks; you might want to look at "all crashes with GoogleURLTracker on the stack of the crashing thread".

Comment 13 by kareng@google.com, Jun 29 2012

ok last night's dev will be out for a week so we'll have a lot of pageloads i will check crash rates and we can decide on july 9th. ty.

Comment 14 by kareng@google.com, Jul 9 2012

hey peter, how has this been on canary? did u have to do follow up patches? this crash is about 1% on dev+beta so i'd like to take it in if it's safe.

I haven't been watching the Canary stats.  I haven't seen any followon bugs assigned to me, FWIW :)

Comment 16 by kareng@google.com, Jul 9 2012

Labels: -Merge-Requested Merge-Approved
ok looks like it fixed this crash. pls merge to 1180. ty so much.
Labels: -Merge-Approved Merge-Merged
Merged in r145760.
Project Member

Comment 18 by bugdroid1@chromium.org, Jul 9 2012

Labels: merge-merged-1180
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=145760

------------------------------------------------------------------------
r145760 | pkasting@chromium.org | Mon Jul 09 15:22:57 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker.cc?r1=145760&r2=145759&pathrev=145760
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker_unittest.cc?r1=145760&r2=145759&pathrev=145760
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker.h?r1=145760&r2=145759&pathrev=145760

Merge 144201 - More comprehensive handling of NOTIFICATION_NAV_ENTRY_PENDING for GoogleURLTracker.

In particular, there are three cases that are improved:
(1) We didn't deal well with further searches in the same tab that was already showing an infobar.  Depending on ordering, various kinds of badness could occur, in particular trying to deref infobar_map_.end().
(2) If we caught a PENDING search, but before the load committed the user performed some other navigation, we'd show the infobar on the commit for the later navigation, leading to infobars on random pages.
(3) In a generalization of (2), we now listen for PENDING in many more cases so that we know if the user is starting a new navigation, which may be the only way we get signalled that a previous navigation has been cancelled.  (Note that if a pending navigation is simply stopped, and we were waiting for commit, we'll keep waiting, but this is harmless since eventually either the tab will be closed or the user will start another navigation.)

These changes should hopefully make GoogleURLTracker as robust about navigation-handling as AlternateNavURLFetcher already was.

Additionally, I reverted a previous change where a pending search would change the "search_url" of a visible infobar in that tab.  Because we don't get notified when a load is stopped, we can't distinguish between "started a new search that hasn't committed" and "started but then cancelled a new search", and thus it's potentially wrong to search for the new URL (yet).  We now once again wait until a search actually commits.  In doing this I simplified things so that we only even pass in the search URL when a load commits.

BUG= 133108 
TEST=Edit your preferences file so that you get prompted about changing Google search URLs.  Do a Google search in one tab, wait for the infobar to appear, then do another search in the same tab.  The infobar should stick around and interacting with it shouldn't cause crashes.
Review URL: https://chromiumcodereview.appspot.com/10630022

TBR=pkasting@chromium.org
------------------------------------------------------------------------
Project Member

Comment 19 by bugdroid1@chromium.org, Jul 10 2012

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

------------------------------------------------------------------------
r145808 | karen@chromium.org | Mon Jul 09 17:28:11 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker.cc?r1=145808&r2=145807&pathrev=145808
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker_unittest.cc?r1=145808&r2=145807&pathrev=145808
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker.h?r1=145808&r2=145807&pathrev=145808

Revert 145760 - Merge 144201 - More comprehensive handling of NOTIFICATION_NAV_ENTRY_PENDING for GoogleURLTracker.

In particular, there are three cases that are improved:
(1) We didn't deal well with further searches in the same tab that was already showing an infobar.  Depending on ordering, various kinds of badness could occur, in particular trying to deref infobar_map_.end().
(2) If we caught a PENDING search, but before the load committed the user performed some other navigation, we'd show the infobar on the commit for the later navigation, leading to infobars on random pages.
(3) In a generalization of (2), we now listen for PENDING in many more cases so that we know if the user is starting a new navigation, which may be the only way we get signalled that a previous navigation has been cancelled.  (Note that if a pending navigation is simply stopped, and we were waiting for commit, we'll keep waiting, but this is harmless since eventually either the tab will be closed or the user will start another navigation.)

These changes should hopefully make GoogleURLTracker as robust about navigation-handling as AlternateNavURLFetcher already was.

Additionally, I reverted a previous change where a pending search would change the "search_url" of a visible infobar in that tab.  Because we don't get notified when a load is stopped, we can't distinguish between "started a new search that hasn't committed" and "started but then cancelled a new search", and thus it's potentially wrong to search for the new URL (yet).  We now once again wait until a search actually commits.  In doing this I simplified things so that we only even pass in the search URL when a load commits.

BUG= 133108 
TEST=Edit your preferences file so that you get prompted about changing Google search URLs.  Do a Google search in one tab, wait for the infobar to appear, then do another search in the same tab.  The infobar should stick around and interacting with it shouldn't cause crashes.
Review URL: https://chromiumcodereview.appspot.com/10630022

TBR=pkasting@chromium.org

TBR=pkasting@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10749017
------------------------------------------------------------------------
Project Member

Comment 20 by bugdroid1@chromium.org, Jul 10 2012

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

------------------------------------------------------------------------
r145828 | pkasting@chromium.org | Mon Jul 09 19:21:10 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker.cc?r1=145828&r2=145827&pathrev=145828
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker_unittest.cc?r1=145828&r2=145827&pathrev=145828
 M http://src.chromium.org/viewvc/chrome/branches/1180/src/chrome/browser/google/google_url_tracker.h?r1=145828&r2=145827&pathrev=145828

Merge 144201 - More comprehensive handling of NOTIFICATION_NAV_ENTRY_PENDING for GoogleURLTracker.

In particular, there are three cases that are improved:
(1) We didn't deal well with further searches in the same tab that was already showing an infobar.  Depending on ordering, various kinds of badness could occur, in particular trying to deref infobar_map_.end().
(2) If we caught a PENDING search, but before the load committed the user performed some other navigation, we'd show the infobar on the commit for the later navigation, leading to infobars on random pages.
(3) In a generalization of (2), we now listen for PENDING in many more cases so that we know if the user is starting a new navigation, which may be the only way we get signalled that a previous navigation has been cancelled.  (Note that if a pending navigation is simply stopped, and we were waiting for commit, we'll keep waiting, but this is harmless since eventually either the tab will be closed or the user will start another navigation.)

These changes should hopefully make GoogleURLTracker as robust about navigation-handling as AlternateNavURLFetcher already was.

Additionally, I reverted a previous change where a pending search would change the "search_url" of a visible infobar in that tab.  Because we don't get notified when a load is stopped, we can't distinguish between "started a new search that hasn't committed" and "started but then cancelled a new search", and thus it's potentially wrong to search for the new URL (yet).  We now once again wait until a search actually commits.  In doing this I simplified things so that we only even pass in the search URL when a load commits.

BUG= 133108 
TEST=Edit your preferences file so that you get prompted about changing Google search URLs.  Do a Google search in one tab, wait for the infobar to appear, then do another search in the same tab.  The infobar should stick around and interacting with it shouldn't cause crashes.
Review URL: https://chromiumcodereview.appspot.com/10630022

TBR=pkasting@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10753019
------------------------------------------------------------------------
Status: Verified
Verified on 21.0.1180.38.
Project Member

Comment 22 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Mstone-21 M-21 Cr-UI
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment