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

Issue 44724 link

Starred by 65 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jun 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug
M-6

Blocking:
issue chromium-os:3489
issue 185301



Sign in to add a comment

Crash - net::internal::ClientSocketPoolBaseHelper::MaybeOnAvailableSocketSlot

Project Member Reported by huanr@chromium.org, May 21 2010

Issue description

Big browser crash spike in 408.1.

http://crash/reportdetail?reportid=ba58680741ce6853

Call stack:

0x67df6109	 [chrome.dll	 - xtree:1264]	
std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,
std::allocator<char> 
>,net::internal::ClientSocketPoolBaseHelper::Group,std::less<std::basic_str
ing<char,std::char_traits<char>,std::allocator<char> > 
>,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,st
d::allocator<char> > const 
,net::internal::ClientSocketPoolBaseHelper::Group> >,0> 
>::_Lbound(std::basic_string<char,std::char_traits<char>,std::allocator<cha
r> > const &)
0x67df46ec	 [chrome.dll	 - client_socket_pool_base.cc:621]	
net::internal::ClientSocketPoolBaseHelper::MaybeOnAvailableSocketSlot(std::
basic_string<char,std::char_traits<char>,std::allocator<char> > const &)
 

Comment 1 by huanr@chromium.org, May 21 2010

Labels: -Pri-2 -Area-Undefined Pri-1 Area-Internals Crash Crash-TopCrasher Internals-Network
Status: Assigned
Browser crash rate more than double because of this.

It happened to me as well. I left with browser open and then when I logged in again I 
saw the browser just crashed dialog.

Comment 2 by huanr@chromium.org, May 21 2010

This one has better stack

http://crash/reportdetail?reportid=63e101a7dc59a8c3#crashing_thread

0x6768612a	 [chrome.dll	 - xtree:1267]	
std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::alloc
ator<char> 
>,net::internal::ClientSocketPoolBaseHelper::Group,std::less<std::basic_string<char,s
td::char_traits<char>,std::allocator<char> > 
>,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocat
or<char> > const ,net::internal::ClientSocketPoolBaseHelper::Group> >,0> 
>::_Lbound(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const 
&)
0x676853aa	 [chrome.dll	 - xtree:987]	
std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::alloc
ator<char> 
>,net::internal::ClientSocketPoolBaseHelper::Group,std::less<std::basic_string<char,s
td::char_traits<char>,std::allocator<char> > 
>,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocat
or<char> > const ,net::internal::ClientSocketPoolBaseHelper::Group> >,0> 
>::find(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)
0x676846ec	 [chrome.dll	 - client_socket_pool_base.cc:621]	
net::internal::ClientSocketPoolBaseHelper::MaybeOnAvailableSocketSlot(std::basic_stri
ng<char,std::char_traits<char>,std::allocator<char> > const &)
0x6768462d	 [chrome.dll	 - client_socket_pool_base.cc:601]	
net::internal::ClientSocketPoolBaseHelper::OnConnectJobComplete(int,net::ConnectJob 
*)
0x6768312f	 [chrome.dll	 - client_socket_pool_base.cc:81]	
net::ConnectJob::NotifyDelegateOfCompletion(int)
0x6766cd87	 [chrome.dll	 - tcp_client_socket_pool.cc:78]	
net::TCPConnectJob::OnIOComplete(int)
0x676448f1	 [chrome.dll	 - callback.h:118]	
CallbackImpl<media::OmxVideoDecodeEngine,void ( 
media::OmxVideoDecodeEngine::*)(OMX_BUFFERHEADERTYPE *),Tuple1<OMX_BUFFERHEADERTYPE 
*> >::RunWithParams(Tuple1<OMX_BUFFERHEADERTYPE *> const &)
0x6762998a	 [chrome.dll	 - host_resolver.cc:67]	
net::SingleRequestHostResolver::OnResolveCompletion(int)
0x676448f1	 [chrome.dll	 - callback.h:118]	
CallbackImpl<media::OmxVideoDecodeEngine,void ( 
media::OmxVideoDecodeEngine::*)(OMX_BUFFERHEADERTYPE *),Tuple1<OMX_BUFFERHEADERTYPE 
*> >::RunWithParams(Tuple1<OMX_BUFFERHEADERTYPE *> const &)
0x6761ceae	 [chrome.dll	 - host_resolver_impl.cc:208]	
net::HostResolverImpl::Request::OnComplete(int,net::AddressList const &)
0x6761de0c	 [chrome.dll	 - host_resolver_impl.cc:972]	
net::HostResolverImpl::OnJobComplete(net::HostResolverImpl::Job 
*,int,int,net::AddressList const &)
0x6761d239	 [chrome.dll	 - host_resolver_impl.cc:417]	
net::HostResolverImpl::Job::OnLookupComplete()
0x66fcb263	 [chrome.dll	 - message_loop.cc:328]	MessageLoop::RunTask(Task *)
0x66fcb2a0	 [chrome.dll	 - message_loop.cc:336]	
MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)
0x66fcb436	 [chrome.dll	 - message_loop.cc:443]	MessageLoop::DoWork()
0x66fdbfe5	 [chrome.dll	 - message_pump_win.cc:466]	
base::MessagePumpForIO::DoRunLoop()
0x66fdbad9	 [chrome.dll	 - message_pump_win.cc:52]	
base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate 
*,base::MessagePumpWin::Dispatcher *)
0x66fdb91e	 [chrome.dll	 - message_pump_win.h:78]	
base::MessagePumpWin::Run(base::MessagePump::Delegate *)
0x66fcb10e	 [chrome.dll	 - message_loop.cc:204]	MessageLoop::RunInternal()
0x66fcb093	 [chrome.dll	 - message_loop.cc:176]	MessageLoop::RunHandler()
0x66fcb041	 [chrome.dll	 - message_loop.cc:154]	MessageLoop::Run()
0x6778e48d	 [chrome.dll	 - thread.cc:133]	base::Thread::Run(MessageLoop 
*)
0x6778e575	 [chrome.dll	 - thread.cc:157]	base::Thread::ThreadMain()

This is most likely a dupe of 44610.  I'm going to keep this open until next week's dev channel (with the revert) 
goes out.

Comment 4 by mark@chromium.org, May 21 2010

 Issue 44685  has been merged into this issue.

Comment 5 by kerz@chromium.org, May 21 2010

 Issue 44754  has been merged into this issue.

Comment 6 by darin@chromium.org, May 22 2010

 Issue 44815  has been merged into this issue.
 Issue 44866  has been merged into this issue.
 Issue 44832  has been merged into this issue.
 Issue 44775  has been merged into this issue.

Comment 10 by wtc@chromium.org, May 24 2010

Labels: Mstone-6
 Issue 44932  has been merged into this issue.
Labels: ReleaseBlock-Dev
 Issue 44970  has been merged into this issue.
 Issue 44890  has been merged into this issue.
 Issue 44987  has been merged into this issue.
 Issue 45063  has been merged into this issue.
 Issue 45163  has been merged into this issue.
 Issue 41870  has been merged into this issue.
 Issue 45232  has been merged into this issue.
 Issue 45238  has been merged into this issue.
 Issue 45266  has been merged into this issue.
 Issue 45183  has been merged into this issue.
 Issue 45338  has been merged into this issue.

Comment 25 by nugun...@gmail.com, May 31 2010

This has been happening for at least a few months now with Chrome 5 dev-channel on 
MacOS X Snow Leopard for me.  Hibernate is a guaranteed crash.
 Issue 45387  has been merged into this issue.
 Issue 45568  has been merged into this issue.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48895 

------------------------------------------------------------------------
r48895 | willchan@chromium.org | 2010-06-03 16:53:34 -0700 (Thu, 03 Jun 2010) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_pool_base.cc?r1=48895&r2=48894
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_pool_base_unittest.cc?r1=48895&r2=48894

Fixes an invalid read bug in ClientSocketPoolBaseHelper and cancels ConnectJobs on network changes.
The bug seems to be running callbacks that delete the ClientSocketPoolBaseHelper object.  We need to hold onto a self-reference in the stack frame.
The new test does not crash, but will trigger invalid reads in valgrind without the fix.
The fixes are overly conservative.  At every entry point that can lead to releasing the last reference, we hold onto a self-reference.  Not all of them can currently lead to crashes since the last operation is running the callback.  But this conservative measure will help future-proof the code in case anyone adds code without thinking about it.  The references are cheap anyway.
BUG= 44724 

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

Status: Fixed
The offending change got reverted before and the dev channel release with the fix is 
out now.  Closing.
It works now. Thanks for the fix!
Here in Windows 7 64-bits is fine too! Thanks.
 Issue 45809  has been merged into this issue.
 Issue 45713  has been merged into this issue.
 Issue 45787  has been merged into this issue.

Comment 35 Deleted

 Issue 46380  has been merged into this issue.
 Issue 44898  has been merged into this issue.

Comment 38 by hbridge@google.com, Jun 23 2010

Labels: -Crash-TopCrasher Crash-TopFixed
It seems it resurfaced in 6.0.466.0
Confirmed.
Confirmed. 6.0.466.0
I also confirm that 6.0.466.0 crashes in Win 7 after resume.
Is there a new issue open for this or will this issue be reopened? Current status is "fixed".
/agree with previous poster -- this issue is not fixed

Comment 44 by huanr@chromium.org, Jul 20 2010

For people seeing this crash again on 466.0, do you have crash dump showing it hit the same call stack as described in the bug or you just see Chrome crashes after resuming from sleep? Can you follow http://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug and send us crash dump ID or crash dump?

Comment 45 by ebl...@gmail.com, Aug 19 2010

I also have this problem with 6.0.472.36. I enabled crash reporting, but I get no crash reports even with it enabled. Because of the nature of the crash (immediately after resuming from hibernate), it seems impossible to use windbg to capture further details. 

Any suggestions on how I can capture the crash dump? This happens every time after a hibernate and is extremely annoying. Thanks!
I do not see any crash reports with this stacktrace anymore for the version you listed.  Maybe that's because users who hit this don't send crash reports, but it sounds unlikely that all users that hit this crash also can't send crash reports.  I'm not sure why it's impossible to use windbg here, since if you start chrome from windbg, it presumably should catch the exception after resuming from hibernate.  I believe this specific instance of the bug to be fixed, so if you can reproduce the bug and get a stacktrace, then please file a new bug with the information.

Comment 47 by ebl...@gmail.com, Aug 23 2010

I was able to get a crash report eventually. This seems to be a dupe of  Issue 49274 .  Crashes stop occurring for me after resuming from hibernate when I disable syncing of extensions and auto fill.
eblau1: Tried your suggestion (syncing of extensions and auto fill disabled) but the problem persists with latest version of google chrome 6.0.472.41. Only happens on my portable PC (ie Chrome crashes whilst the PC is still negotiating wifi connection with my router). Enabled crash report but none written.
Like you guys, I wasn't able to get a crash report after failure but since version 6.0.495.0 i haven't seen this bug.
to me,  issue 44724  is fixed.
Labels: -Crash bulkmove Stability-Crash
Big browser crash spike in 408.1.

http://crash/reportdetail?reportid=ba58680741ce6853

Call stack:

0x67df6109	 [chrome.dll	 - xtree:1264]	
std::_Tree&lt;std::_Tmap_traits&lt;std::basic_string&lt;char,std::char_traits&lt;char&gt;,
std::allocator&lt;char&gt; 
&gt;,net::internal::ClientSocketPoolBaseHelper::Group,std::less&lt;std::basic_str
ing&lt;char,std::char_traits&lt;char&gt;,std::allocator&lt;char&gt; &gt; 
&gt;,std::allocator&lt;std::pair&lt;std::basic_string&lt;char,std::char_traits&lt;char&gt;,st
d::allocator&lt;char&gt; &gt; const 
,net::internal::ClientSocketPoolBaseHelper::Group&gt; &gt;,0&gt; 
&gt;::_Lbound(std::basic_string&lt;char,std::char_traits&lt;char&gt;,std::allocator&lt;cha
r&gt; &gt; const &amp;)
0x67df46ec	 [chrome.dll	 - client_socket_pool_base.cc:621]	
net::internal::ClientSocketPoolBaseHelper::MaybeOnAvailableSocketSlot(std::
basic_string&lt;char,std::char_traits&lt;char&gt;,std::allocator&lt;char&gt; &gt; const &amp;)
I will change the navigator because of this bug!

@vladimir: I don't understand comment #51. Are you still experiencing this crash? If so please provide us with a crash report ID -- see http://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug
Yes, I´m still experiencing this crash. I´ve just restarted my computer. Now I turned off the bookmark sync because I read it can be the cause of it.

Please follow the instructions in comment #52. Go to chrome://crashes and file a new bug for the crash.

You can past the new bug ID here so I can add myself to it.
Can't believe this issue isn't fixed yet, still happening on Win 7 64bit, even after restarting the WLAN service and Chrome.exe (doesn't even restart properly) becomes non responsive after hibernating.
It should be noted that a few instances of dllhost.exe appears in windows processes while all this is happening... 
Project Member

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

Labels: -Area-Internals -Internals-Network -Mstone-6 M-6 Cr-Internals Cr-Internals-Network
In my case, issue just began a few weeks ago.
HP DV-4270US Pavilion
Chrome Version 43.0.2357.130 m
Win 7 Pro 64 bit SP1
c#58: Given the gap between the bug being fixed and your report, it strikes me as very likely you're seeing a new bug, and bugs that have been closed don't generally get much attention.  Can you file a new bug at http://crbug.com/new describing in detail what you're seeing, and if it looks network related to you, could you also include a net-internals dump?  (See https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details for how to do that.)  Thanks very much.

Sign in to add a comment