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

Issue 130772 link

Starred by 9 users

Issue metadata

Status: Archived
Last visit > 30 days ago
Closed: Aug 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

issue 123830

Sign in to add a comment

crashing while fetching pac script (system url request context) during shutdown

Project Member Reported by, Jun 1 2012

Issue description

Product: Chrome
Stack Signature: base::debug::BreakDebugger()-18B549E
New Signature Label: base::debug::BreakDebugger()
New Signature Hash: 709aa75d_83ac9070_8d0c0e87_4744031f_4f3a1fe3

Report link: http://go/crash/reportdetail?reportid=6f0fc2047867de29

Meta information:
Product Name: Chrome
Product Version: 21.0.1155.2
Report ID: 6f0fc2047867de29
Report Time: 2012/05/31 00:45:37, Thu
Uptime: 18 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 23 stepping 10

The following are couple of URLs that were pointed out by 	net::URLRequestContext::AssertNoURLRequests.

This seems to have started in 1144:, but not in (these crashes are in ProfileIOData shutdown, so it's a different URLRequestContext, not the PAC context).
Status: Assigned
If we leak Profiles, then the PAC fetcher context may have ongoing URLRequests on behalf of those Profiles. We need to not leak Profiles.
In Beta (M20), it is one of top 50 crashes.

In Dev (M21), it is among the top 10 crashes
Labels: Mstone-21 Stability-Crash ReleaseBlock-Beta
mad - should the change mentioned in comment #2 be reverted?

Comment 6 by, Jun 21 2012

This is not a profile leak it's a render process host leak... if the
profile goes away before the render process host, we can get crashes... we
need to fix the render process host leak...

sent from Mobile Answering Device!
Le 6 juin 2012 18:01, <> a 

Comment 7 by, Jun 21 2012

As an experiment, I will change the destruction delay to a DCHECK, so that we can catch to render process leak / late delays, and then see if the number of crashes we get from render process hosts holding on to a dead profile or not quite as bad as this one...
Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
Yes, the root cause is the RenderProcessHost leak. We need to fix that. But r138038 causes a RenderProcessHost leak to *also* cause a profile leak. IIUC, r138038 should get reverted, since we're just shuffling around where the crash happens, not actually fixing a crash.

Comment 10 by, Jun 21 2012

There are still cases where the fix actually resolve crashes where the render process host didn't leak, it just got released later than the Profile because all this is independently asynchronous... But I guess these should be fixed in some other ways too... :-(
Getting released later than the Profile is a leak in this case, because RenderProcessHost is a UI thread object. The Profile gets deleted after the MessageLoop on the UI thread has stopped pumping events. That means that by the time the ProfileManager starts deleting Profiles, if the RenderProcessHost isn't gone, then it will be leaked, since the MessageLoop will not run any more tasks, so it won't just get deleted later, but it will be completely leaked.

Comment 12 by, Jun 21 2012

I don't think this is the case for incognito profile... Which is why this initially only took care of incognito profiles... Which eventually caused problems when incognito profile outlived parent profile...
Yes, sorry for being imprecise. My statement is only true for normal profiles. But as you point out, due to the dependency between incognito profiles and normal profiles, we need to either make profiles live longer (and everything that depends on those profiles live longer), or we need to make sure that everything that uses profiles gets destroyed promptly.

There are a few points to keep in mind here. Even if we decide to let Profiles live longer, it's not acceptable to ever leak them, since then we aren't persisting lots of their data on shutdown, which is clearly a bug. So, we we want to keep Profiles alive longer, and not leak them, then we need to keep pumping the UI MessageLoop. Of course, during shutdown, we've never done this, so re-pumping the UI MessageLoop would probably lead to a lot of bugs. Also, allowing things to keep objects alive longer is an inversion of ownership. Profiles own all these profile-related objects like RenderProcessHost, so those objects should not keep Profiles alive.

As I think we've agreed on, the real solution is to track down this RenderProcessHost delayed shutdown issue and figure out how to make it get destroyed promptly.

Comment 14 by, Jun 22 2012

Labels: -Pri-2 Pri-1
Project Member

Comment 15 by, Jun 26 2012

The following revision refers to this bug:

r144251 | | Tue Jun 26 13:09:16 PDT 2012

Changed paths:

Now doesn't wait to destroy non-incognito profiles, and allow immediate destruction of incognito profiles from their parent profile. Also, doesn't wait infinitely for render process hosts to go away, uses a timer to complete destruction. And finally, adds DCHECKs to identify when render process hosts are dead soon enough.

BUG= 130772 
TEST=Make sure Chrome exits without a crash and that Profile info properly got saved. Also make sure info doesn't leak from one incognito session to another.

Review URL:

Comment 16 by, Jun 26 2012

Labels: Merge-Requested

Comment 17 by, Jun 26 2012

let me know once this has made to canary and has been verified. pls. :)

Comment 18 by, Jun 26 2012

OK, will do... :-)

Comment 19 by, Jun 29 2012

Seems like the crash is still happening with the fix... :-(

There are a few occurrences in 1188 which was cut after the fix got it (but none yet in 1189, not sure why though, too soon?)...

So either the fix isn't correct, or the problem wasn't caused by the profile destroyer... :-/

We need to go deeper...

Comment 20 by, Jun 29 2012

Labels: -Merge-Requested
ok so removing merge request for now :)

Comment 21 by, Jun 29 2012

Labels: Merge-Requested
Actually, I take that back, the issues we are seeing after the fix I made were not related, they were in the destructor of the ProfileIOData, so not related as mentioned by willchan in comment 1 above...

There were no occurrence of the non-ProfileIOData destructor crash after this fix, so I guess we are good to go with the merge...

Unless I'm missing something again...

Comment 22 by, Jun 29 2012

hmm. we have a bit more time for beta2, would u like to stew this a bit? u can merge all the way to july 10 and still be in beta2 at this moment.

Comment 23 by, Jun 29 2012

I personally don't mind as lo g as the other stake holders are OK with it...

sent from Mobile Answering Device!
Le 29 juin 2012 13:27, <> a 

Comment 24 by, Jun 29 2012

there are no builds between now and then anyway so it's not possible to get it out sooner, might as well wait and make sure there are no side effects.
Blocking: chromium:123830

Comment 26 by, Jul 9 2012

Labels: -Merge-Requested Merge-Approved

Comment 27 by, Jul 9 2012

Status: Fixed
Project Member

Comment 28 by, Jul 9 2012

Labels: -Merge-Approved merge-merged-1180
The following revision refers to this bug:

r145740 | | Mon Jul 09 14:14:22 PDT 2012

Changed paths:

Merge 144251 - Now doesn't wait to destroy non-incognito profiles, and allow immediate destruction of incognito profiles from their parent profile. Also, doesn't wait infinitely for render process hosts to go away, uses a timer to complete destruction. And finally, adds DCHECKs to identify when render process hosts are dead soon enough.

BUG= 130772 
TEST=Make sure Chrome exits without a crash and that Profile info properly got saved. Also make sure info doesn't leak from one incognito session to another.

Review URL:
Review URL:

Comment 29 Deleted

Comment 30 Deleted

We had 4 crashes in 22.0.1200.0	in net::URLRequestContext::AssertNoURLRequests.

The following are couple of URLs.

crash id: 6c802a8f5d028365 crashing while deleting SystemURLRequestContext (or non-ProfileIOData).

The following is one call stack:

Thread 13 *CRASHED* ( EXCEPTION_BREAKPOINT @ 0x62d68a75 )

0x62d68a75	 [chrome.dll]	 -	
0x62d31f82	 [chrome.dll]	 -	
0x62d31fce	 [chrome.dll]	 -	
0x62d3850c	 [chrome.dll]	 + 0x0050850c]	
`anonymous namespace'::SystemURLRequestContext::`scalar deleting destructor'(unsigned int)
0x62d38459	 [chrome.dll]	 -	
0x62d382ef	 [chrome.dll]	 -	
0x629ab5a6	 [chrome.dll]	 -	

The following is another call stack (crash during ProfileIOData).
Thread 12 *CRASHED* ( EXCEPTION_BREAKPOINT @ 0x6bf17e81 )

0x6bf17e81	 [chrome.dll]	 -	
0x6bee3a0d	 [chrome.dll]	 -	
0x6bee815c	 [chrome.dll]	 -	
0x6bee5928	 [chrome.dll]	 + 0x00505928]	
ProfileImplIOData::`vector deleting destructor'(unsigned int)

Crash ids in 22.0.1200.0 are:

Comment 32 by, Jul 9 2012

Labels: -ReleaseBlock-Stable
Owner: ----
Status: Available
Oh! Yeah, right, this bug is the more generic one... I was taking this one as just failing because the ProfileDestroyer was holding on Profile objects for too long...

But now that we have fixed the most frequent cause of this symptom, maybe we can remove the ReleaseBlock-Stable label?

And I also remove myself as a owner and make the bug available since I don't know this code that much, I was just owner to fix the ProfileDestroyer issue (which I also don't own, but I had volunteered to introduce to fix another problem many months ago).


Comment 33 by, Aug 14 2012

Status: Assigned looks like u added the CHECK will and i still see this crash on 23.0.1235.0

Comment 34 by, Aug 14 2012 looks like u added the CHECK will and i still see this crash on 23.0.1235.0
Karen, how many crashes are we seeing? Raman, can update the bug with the latest URLs we see? I want to know if we're seeing new, different kinds of URLs due to regressions, or if it's still the same slow trickle due to profile destruction being all messed up.
There were only 3 crashes in 23.0.1235.0 until 8/14 5:04pm PST.
Looks like the profile is getting leaked. This should be a different bug,
it's not the PAC script fetcher. But yeah, until we fix the profile leakage
(which has some other implications), we will continue to have issues.

Comment 39 by, Sep 2 2012

i see 13 in today's canary. is this not fixable at this point?
Issue 144260 has been merged into this issue.

Comment 41 by, Sep 23 2012

recently this is showing up on the top. Is there a recent regression causing the spike?
I'm seeing something that looks similar to this in R25 on Chrome OS.  Is this the same bug?

0x73f44109	 [chrome]	 - base/debug/]	base::debug::BreakDebugger()
0x73fb3ad9	 [chrome]	 - net/url_request/]	net::URLRequestContext::AssertNoURLRequests() const
0x73cad9f1	 [chrome]	 - chrome/browser/profiles/]	ProfileIOData::~ProfileIOData()
0x73e2dd19	 [chrome]	 - chrome/browser/profiles/]	OffTheRecordProfileIOData::~OffTheRecordProfileIOData()
0x73e2dd2b	 [chrome]	 - chrome/browser/profiles/]	OffTheRecordProfileIOData::~OffTheRecordProfileIOData()
0x73cacd69	 [chrome]	 - ./base/sequenced_task_runner_helpers.h:39]	base::DeleteHelper<ProfileIOData>::DoDelete(void const*)
0x75a36f87	 [chrome]	 - ./base/bind_internal.h:171]	base::internal::Invoker<1, base::internal::BindState<base::internal::RunnableAdapter<void (*)(void const*)>, void (void const*), void (void const*)>, void (void const*)>::Run(base::internal::BindStateBase*)
0x7585c4ff	 [chrome]	 - ./base/callback.h:391]	MessageLoop::RunTask(base::PendingTask const&)
0x7585c465	 [chrome]	 - base/]	MessageLoop::DeferOrRunPendingTask(base::PendingTask const&)
0x75846fdb	 [chrome]	 - base/]	MessageLoop::DoWork()
0x75856da1	 [chrome]	 - base/]	base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)
0x75846dbb	 [chrome]	 - base/]	MessageLoop::RunInternal()
0x75846d4d	 [chrome]	 - base/]	base::RunLoop::Run()
0x75846cab	 [chrome]	 - base/]	MessageLoop::Run()
0x758a7033	 [chrome]	 - content/browser/]	content::BrowserThreadImpl::IOThreadRun(MessageLoop*)
0x7589dac5	 [chrome]	 - content/browser/]	content::BrowserThreadImpl::Run(MessageLoop*)
0x75846901	 [chrome]	 - base/threading/]	base::Thread::ThreadMain()
0x758468a3	 [chrome]	 - base/threading/]	base::::ThreadFunc
0x73601089	 []	 - pthread_create.c:307]	start_thread

This is an incognito request leak. Can you repro in a debugger? Or somehow get the stack data from a crash dump? In URLRequestContext::AssertNoURLRequests(), we'll record the URL requested and the allocation stack trace, so we can debug the leak. More likely than not, it's a regression. All types of regressions will fall into this same stack trace, and we have to analyze the stack to determine the root cause. So I recommend you file a separate bug and cc me on it.
Project Member

Comment 45 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Mstone-21 M-21 Cr-Internals Cr-Internals-Network

Comment 46 by, May 22 2013

Labels: -M-21 M-28
Howdy folks, we are still seeing this crash in Chrome 28 (28.0.1500.20) and it represents about 1% of the browser crashes.

Would greatly appreciate some help putting this monkey to bed, since it looks like it's been poking us since the early 20s.'Chrome'%20AND%20product.version%3D'28.0.1500.20'%20AND%20custom_data.ChromeCrashProto.ptype%3D'browser''net%3A%3AURLRequestContext%3A%3AAssertNoURLRequests'
Seeing something similar on shutdown in CrOS R29:

 Issue 252538  has been merged into this issue.

Comment 50 by, Aug 28 2015

Status: Archived

Sign in to add a comment