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

Issue 87176 link

Starred by 19 users

Issue metadata

Status: Fixed
Owner:
OOO until Jan 2
Closed: Mar 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Crash when creating a new tab while the previous one is still loading

Reported by therealh...@gmail.com, Jun 22 2011

Issue description

Chrome Version : (>stable release) 14.0.801.0 (90092)
Windows : XP SP3

This seems to be a Windows specific crash since I can't reproduce it on Linux (Ubuntu 11.04). Also, I can only reproduce it with ToT builds and not with release versions.

I haven't tried dev/beta builds though.

What steps will reproduce the problem? (not related to Google.com, other sites may also work)
1. Launch Chromium/Chrome on Windows with one tab and open Google.com
2. Add a second tab and open Google.com
3. While the second tab is loading, press Ctrl-T (or click "+") to open a third tab (may be timing related, so the exact moment you press Ctrl-T (or click "+") determines whether the repro works or not!)

What is the expected result?

The creation and opening of a new tab

What happens instead?

The new tab crashes

Other information?

I've tried to repro this issue in a debugger, but I failed to get a crash report from NTSD. It only returned an end of process message without any access issues. 

Also the crash does not occur when running in "single-process" mode.

 

Comment 1 by meh...@chromium.org, Jun 23 2011

Labels: Stability-Crash
Labels: Action-FeedbackNeeded
Can you try with Google Chrome Canary and see if it crashes there too?
Yes! Same crash with 14.0.802.0 canary.

Comment 4 by meh...@chromium.org, Jun 24 2011

Please go to chrome://crashes/ and post the recent report_id here. Thanks.
I have done just that, but no crash report appeared. There are no issues reported when Chrome is connected to a debugger either. 

However, the AW, Snap message is displayed and the connected process ends (I can see that from the debugger).
015bff48 7c7d2455 00000001 00000000 015bffa8 ntdll!KiFastSystemCallRet
015bff58 01eebfe1 00000001 01001d80 01f3bdf7 kernel32!Sleep+0xf
015bff6c 01eeb02b 02889f7a 0106e630 531d213d chrome!v8__internal__SamplerThread_
_Run+0x61
015bff70 02889f7a 0106e630 531d213d 01f3bdf7 chrome!v8__internal__ThreadEntry+0x
b
015bffa8 0288a022 0012f244 015bffec 7c7db729 chrome!_callthreadstartex+0x1b
015bffb4 7c7db729 01001d80 01f3bdf7 0012f244 chrome!_threadstartex+0x82
015bffec 00000000 02889fa0 01001d80 00000000 kernel32!GetModuleFileNameA+0x1ba

This is the only trace information I could get from (a breakpoint @) the end of the process of the crashed tab (NTSD with ToT). There is no crash reported so I do not know how to proceed.
After walking the stack manually (!!!), I found that the crash (or end of process) happens in: 

(01f38380)   chrome!v8__internal__Deserializer__ReadObject+0x67   
(01f383f0)  chrome!v8__internal__Deserializer__ReadChunk

However, no matter what I do, after the crash this is always the last part of the stack trace.   

In order of stack walking:

(7c90d20e)   ntdll!NtDelayExecution+0xc  
(7c90d21e)   ntdll!NtDeleteAtom
(7c7d23a0)   kernel32!SleepEx+0x51  
(7c7d2446)   kernel32!Sleep
(7c7d2446)   kernel32!Sleep   
(7c7d24b7)   kernel32!ReleaseMutex
(01ee7890)   chrome!v8__internal__Win32Mutex__Unlock+0xa   
(01ee78a0)   chrome!v8__internal__Win32Mutex__TryLock
(7c809828)   kernel32!ValidateLocale+0x2b0   
(7c81495d)   kernel32!SetUnhandledExceptionFilter
(7c7d2446)   kernel32!Sleep+0x1a   
(7c7d24b7)   kernel32!ReleaseMutex
(7c7d2446)   kernel32!Sleep+0xf   
(7c7d24b7)   kernel32!ReleaseMutex
(01ee84e0)   chrome!v8__internal__SamplerThread__Run+0x61   
(01ee8550)   chrome!v8__internal__ObjectVisitor__VisitPointer
(01f38380)   chrome!v8__internal__Deserializer__ReadObject+0x67   
(01f383f0)   chrome!v8__internal__Deserializer__ReadChunk

If I take the Windows part out of it, 

(01ee7890)   chrome!v8__internal__Win32Mutex__Unlock+0xa   
(01ee78a0)   chrome!v8__internal__Win32Mutex__TryLock
(01ee84e0)   chrome!v8__internal__SamplerThread__Run+0x61   
(01ee8550)   chrome!v8__internal__ObjectVisitor__VisitPointer
(01f38380)   chrome!v8__internal__Deserializer__ReadObject+0x67   
(01f383f0)   chrome!v8__internal__Deserializer__ReadChunk

I do not know if this is helpful at all. It is possible that a sophisticated error occurs that is not picked up by the debugger. 

If it not helpful, the stack can be used to trace other addresses since (at least to me) this issue is still easy to reproduce. I added a video of the original repro to show just that.

screenvideo_issue_87176.wmv
538 KB Download

Comment 9 by meh...@chromium.org, Jun 26 2011

Labels: -Area-Undefined Area-UI OS-Mac Feature-Navigation
Status: Untriaged
Thanks for your help.

I can reproduce it with Google Chrome 14.0.797.0 dev on Mac OS 10.6.8. (Please see the enclosed screenshot).

But it seems, that this is fixed in the latest Canary-Build 33353314.0.803.0 (Official Build 90483).

Is it also fixed for you in the latest Canary-Build?

Note: This issue is similar to  issue 86452  (same issue in Incognito Window).
Bildschirmfoto 2011-06-26 um 11.25.18.png
74.1 KB View Download
No, it is *NOT* fixed in 14.0.803.0 canary :-(

I can still reproduce it ...
Bildschirmfoto 2011-06-26 um 14.03.45.png
112 KB View Download
Labels: -Action-FeedbackNeeded
Chromium 14.0.804.0 (90521) has also this issue !
 Issue 86452  has been merged into this issue.
Note: The merged  issue 86452  is about the same issue, but only in Incognito Mode.
Cc: thestig@chromium.org rsesek@chromium.org
Crash-ID: 5b23267b002eeaff

I hope the id is related to this crash !


Mehmet: that crash just looks like an about:crash crash.
Cc: kasperl@chromium.org
Owner: ager@chromium.org
Status: Assigned
Based on the stacks on the STRs, this looks like a race condition in v8.

Comment 17 by ager@chromium.org, Jun 28 2011

I haven't been able to reproduce this. Are you sure that the stack trace you are showing here is from the thread that crashed? This looks like our sampler thread that is sleeping. I don't think that is what crashed the renderer. I'll attempt to reproduce some more and catch it in a debugger.

Comment 18 by ager@chromium.org, Jun 28 2011

Cc: vitalyr@chromium.org danno@chromium.org
It is (partly?) from a sleeping thread. I only get a visual crash. I used the breakpoint at the end of the child process, because, according to the debugger, nothing out of the ordinary happened.

I can still reproduce the issue on 14.0.806.0 (90747) with XP SP3. And, again, no exception is thrown in the debugger.

Comment 20 by ager@chromium.org, Jun 28 2011

How are you starting the debugger. In order to get the renderer processes into the debugger you have to start chrome with --debug-children which will start each child in a new debugger window. However, at that time it might become hard to reproduce the crash. If you just stop at the end the stack trace will be for the browser process and not the renderer.
I use NTSD with the -o and -g option. Otherwise the breakpoint at the end of the tab process would never hit anyway. The -g option is important, because otherwise the issue would be impossible to reproduce.

I've seen that there are a lot of Chrome command-line parameters which I do not all understand. Maybe there are some that I can use?
I just reproduced it with WinDbg (options: -g and --debug-children). However, the outcome is exactly the same as with NTSD (only the GUI and verbosity differ).

There is no exception, only a breakpoint at the end of the (child) process that shows the Aw, Snap message. Walking the stack from here has the same output as #7 and #8.

After continuing however, I got the following message.

eax=0a82f3ad ebx=00000001 ecx=0a82f3ad edx=7c90e514 esi=01042974 edi=03419450
eip=03419450 esp=0012fc80 ebp=0012fcc0 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
chrome_1c30000!talk_base::`dynamic atexit destructor for 'kWhitespace'':
03419450 833d0863980310  cmp     dword ptr [chrome_1c30000!kWhitespace+0x18 (03986308)],10h ds:0023:03986308=0000000f

and the stacktrace is:

0012fc7c 01c39531 chrome_1c30000!talk_base::`dynamic atexit destructor for 'kWhitespace''
0012fcc0 01c39600 chrome_1c30000!doexit+0x94 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 591]
0012fcd0 01c39fc5 chrome_1c30000!_cexit+0xb [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 427]
0012fce0 01c3a0f7 chrome_1c30000!_CRT_INIT+0xac [f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c @ 178]
0012fd20 01c3a162 chrome_1c30000!__DllMainCRTStartup+0xa9 [f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c @ 340]
0012fd2c 7c90118a chrome_1c30000!_DllMainCRTStartup+0x1e [f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c @ 281]
WARNING: Stack unwind information not available. Following frames may be wrong.
0012fd4c 7c9224ca ntdll!LdrInitializeThunk+0x24
0012fdd0 7c7ecaae ntdll!RtlDestroyEnvironment+0x178
0012fec4 7c7ecb26 kernel32!IsValidLocale+0x8eb
0012fed8 0043d500 kernel32!ExitProcess+0x14
0012fee4 0043d6ec chrome!__crtExitProcess+0x17 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 731]
0012ff28 0043d716 chrome!doexit+0x113 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 644]
0012ff3c 0043c4f5 chrome!exit+0x11 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 412]
0012ffc0 7c7e7077 chrome!__tmainCRTStartup+0x120 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 272]
0012fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49

I continued again got:

eax=00000001 ebx=00000000 ecx=01007940 edx=000007a8 esi=01007940 edi=010077c0
eip=0296def0 esp=0012f7d8 ebp=034475f8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210202
chrome_1c30000!ObserverListThreadSafe<syncable::TransactionObserver>::~ObserverListThreadSafe<syncable::TransactionObserver>:
0296def0 83ec0c          sub     esp,0Ch

With stacktrace:

0012f7d4 0227cedd chrome_1c30000!ObserverListThreadSafe<syncable::TransactionObserver>::~ObserverListThreadSafe<syncable::TransactionObserver> [c:\b\build\slave\win\build\src\base\observer_list_threadsafe.h @ 183]
0012f874 01c5b87b chrome_1c30000!base::SystemMonitor::~SystemMonitor+0x8d [c:\b\build\slave\win\build\src\base\system_monitor\system_monitor.cc @ 45]
0012fbe8 01c387ff chrome_1c30000!RendererMain+0x3eb [c:\b\build\slave\win\build\src\content\renderer\renderer_main.cc @ 234]
0012fc9c 01c39023 chrome_1c30000!`anonymous namespace'::RunNamedProcessTypeMain+0x10f [c:\b\build\slave\win\build\src\chrome\app\chrome_main.cc @ 531]
0012fe54 00405384 chrome_1c30000!ChromeMain+0x7e3 [c:\b\build\slave\win\build\src\chrome\app\chrome_main.cc @ 852]
0012fed0 00407e01 chrome!MainDllLoader::Launch+0x194 [c:\b\build\slave\win\build\src\chrome\app\client_util.cc @ 255]
0012ff30 0043c4e7 chrome!wWinMain+0xa1 [c:\b\build\slave\win\build\src\chrome\app\chrome_exe_main_win.cc @ 47]
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - 
0012ffc0 7c7e7077 chrome!__tmainCRTStartup+0x112 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 263]
WARNING: Stack unwind information not available. Following frames may be wrong.
0012fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49

I continued again:

eax=00000016 ebx=036c1f30 ecx=00000001 edx=00000015 esi=00000016 edi=036c1ed8
eip=02bc4fa2 esp=0012f024 ebp=0012f068 iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010297
chrome_1c30000!WebCore::getExceptionCodeDescription+0x262:
02bc4fa2 8b3c97          mov     edi,dword ptr [edi+edx*4] ds:0023:036c1f2c={chrome_1c30000!`string' (036c1d30)}

with trace:

0012f034 02ac64fa chrome_1c30000!WebCore::getExceptionCodeDescription+0x262 [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\dom\exceptioncode.cpp @ 362]
0012f078 02ab7db8 chrome_1c30000!WebCore::V8Proxy::setDOMException+0x1a [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\bindings\v8\v8proxy.cpp @ 660]
0012f080 033a2435 chrome_1c30000!WebCore::throwError+0x18 [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\bindings\v8\v8proxy.h @ 404]
0012f0a4 033a2508 chrome_1c30000!WebCore::storageSetter+0xc5 [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\bindings\v8\custom\v8storagecustom.cpp @ 112]
0012f0b4 01ee1e68 chrome_1c30000!WebCore::V8Storage::namedPropertySetter+0x18 [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\bindings\v8\custom\v8storagecustom.cpp @ 127]
0012f10c 01ee2501 chrome_1c30000!v8::internal::JSObject::SetPropertyWithInterceptor+0x208 [c:\b\build\slave\win\build\src\v8\src\objects.cc @ 1762]
0012f150 01ee3379 chrome_1c30000!v8::internal::JSObject::SetPropertyForResult+0x351 [c:\b\build\slave\win\build\src\v8\src\objects.cc @ 2372]
0012f184 01ef5ff7 chrome_1c30000!v8::internal::JSReceiver::SetProperty+0xa9 [c:\b\build\slave\win\build\src\v8\src\objects.cc @ 1783]
0012f1a8 01f8ccdd chrome_1c30000!v8::internal::SetProperty+0x27 [c:\b\build\slave\win\build\src\v8\src\handles.cc @ 270]
0012f1ec 01fc4ce2 chrome_1c30000!v8::internal::Runtime::SetObjectProperty+0x1cd [c:\b\build\slave\win\build\src\v8\src\runtime.cc @ 4058]
0012f23c 01fc50e0 chrome_1c30000!v8::internal::KeyedStoreIC::Store+0x2a2 [c:\b\build\slave\win\build\src\v8\src\ic.cc @ 1877]
0012f32c 01efacc5 chrome_1c30000!v8::internal::KeyedStoreIC_Miss+0x80 [c:\b\build\slave\win\build\src\v8\src\ic.cc @ 2137]
0012f364 01efb4cf chrome_1c30000!v8::internal::Invoke+0x115 [c:\b\build\slave\win\build\src\v8\src\execution.cc @ 122]
0012f38c 01ec4481 chrome_1c30000!v8::internal::Execution::Call+0x5f [c:\b\build\slave\win\build\src\v8\src\execution.cc @ 158]
0012f3e8 02ac6bcf chrome_1c30000!v8::Script::Run+0x181 [c:\b\build\slave\win\build\src\v8\src\api.cc @ 1565]
0012f424 02ac6e03 chrome_1c30000!WebCore::V8Proxy::runScript+0x12f [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\bindings\v8\v8proxy.cpp @ 435]
0012f474 02b049ce chrome_1c30000!WebCore::V8Proxy::evaluate+0x1c3 [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\bindings\v8\v8proxy.cpp @ 389]
0012f4b0 02ca36b6 chrome_1c30000!WebCore::ScriptController::evaluate+0xce [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\bindings\v8\scriptcontroller.cpp @ 194]
0012f4d0 02ca3d0d chrome_1c30000!WebCore::ScriptElement::executeScript+0x76 [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\dom\scriptelement.cpp @ 285]
0012f540 02be1b33 chrome_1c30000!WebCore::ScriptElement::execute+0x4d [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\dom\scriptelement.cpp @ 308]
0012f570 02d1014b chrome_1c30000!WebCore::ScriptRunner::timerFired+0x1b3 [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\dom\scriptrunner.cpp @ 115]
0012f578 02d3042f chrome_1c30000!WebCore::Timer<WebCore::MediaPlayer>::fired+0xb [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\platform\timer.h @ 100]
0012f5e4 0227382d chrome_1c30000!WebCore::ThreadTimers::sharedTimerFiredInternal+0xbf [c:\b\build\slave\win\build\src\third_party\webkit\source\webcore\platform\threadtimers.cpp @ 115]
0012f5ec 022750f2 chrome_1c30000!`anonymous namespace'::TaskClosureAdapter::Run+0xd [c:\b\build\slave\win\build\src\base\message_loop.cc @ 105]
0012f6b0 02276ae7 chrome_1c30000!MessageLoop::RunTask+0x162 [c:\b\build\slave\win\build\src\base\message_loop.cc @ 484]
0012f6f0 022a5d92 chrome_1c30000!MessageLoop::DoWork+0x257 [c:\b\build\slave\win\build\src\base\message_loop.cc @ 694]
0012f7b4 02274f7e chrome_1c30000!base::MessagePumpDefault::Run+0x122 [c:\b\build\slave\win\build\src\base\message_pump_default.cc @ 50]
0012f85c 0227658b chrome_1c30000!MessageLoop::RunInternal+0x9e [c:\b\build\slave\win\build\src\base\message_loop.cc @ 451]
0012f874 01c5b807 chrome_1c30000!MessageLoop::Run+0x5b [c:\b\build\slave\win\build\src\base\message_loop.cc @ 349]
0012fbe8 01c387ff chrome_1c30000!RendererMain+0x377 [c:\b\build\slave\win\build\src\content\renderer\renderer_main.cc @ 229]
0012fc9c 01c39023 chrome_1c30000!`anonymous namespace'::RunNamedProcessTypeMain+0x10f [c:\b\build\slave\win\build\src\chrome\app\chrome_main.cc @ 531]
0012fe54 00405384 chrome_1c30000!ChromeMain+0x7e3 [c:\b\build\slave\win\build\src\chrome\app\chrome_main.cc @ 852]
0012fed0 00407e01 chrome!MainDllLoader::Launch+0x194 [c:\b\build\slave\win\build\src\chrome\app\client_util.cc @ 255]
0012ff30 0043c4e7 chrome!wWinMain+0xa1 [c:\b\build\slave\win\build\src\chrome\app\chrome_exe_main_win.cc @ 47]
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - 
0012ffc0 7c7e7077 chrome!__tmainCRTStartup+0x112 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 263]
WARNING: Stack unwind information not available. Following frames may be wrong.
0012fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49

I hope this is helpful. At least it looks more helpful than the #7 and #8 stacktraces. It is remarkable that these exceptions only occur after the tab has crashed.

And the last one when ending the debug session.

ax=01000e98 ebx=01077360 ecx=039a75f4 edx=010772d0 esi=039a75f4 edi=01000e98
eip=0249aec0 esp=0012fb00 ebp=00000000 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
chrome_1c30000!std::_Tree<std::_Tmap_traits<enum SecurityStyle,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<enum SecurityStyle>,std::allocator<std::pair<enum SecurityStyle const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,0> >::_Erase:
0249aec0 53              push    ebx

with trace:

0012fafc 024876c8 chrome_1c30000!std::_Tree<std::_Tmap_traits<enum SecurityStyle,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<enum SecurityStyle>,std::allocator<std::pair<enum SecurityStyle const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,0> >::_Erase [c:\program files (x86)\microsoft visual studio 9.0\vc\include\xtree @ 1166]
0012fb18 022d2dc3 chrome_1c30000!std::_Tree<std::_Tmap_traits<enum DownloadItem::DownloadState,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<enum DownloadItem::DownloadState>,std::allocator<std::pair<enum DownloadItem::DownloadState const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,0> >::erase+0x58 [c:\program files (x86)\microsoft visual studio 9.0\vc\include\xtree @ 937]
0012fb40 0227c686 chrome_1c30000!base::LazyInstance<std::map<int,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<int>,std::allocator<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >,base::DefaultLazyInstanceTraits<std::map<int,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<int>,std::allocator<std::pair<int const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > > > >::OnExit+0x23 [c:\b\build\slave\win\build\src\base\lazy_instance.h @ 184]
0012fbfc 0227c77d chrome_1c30000!base::AtExitManager::ProcessCallbacksNow+0x116 [c:\b\build\slave\win\build\src\base\at_exit.cc @ 68]
0012fca4 01c390a4 chrome_1c30000!base::AtExitManager::~AtExitManager+0xcd [c:\b\build\slave\win\build\src\base\at_exit.cc @ 39]
0012fe54 00405384 chrome_1c30000!ChromeMain+0x864 [c:\b\build\slave\win\build\src\chrome\app\chrome_main.cc @ 861]
0012fed0 00407e01 chrome!MainDllLoader::Launch+0x194 [c:\b\build\slave\win\build\src\chrome\app\client_util.cc @ 255]
0012ff30 0043c4e7 chrome!wWinMain+0xa1 [c:\b\build\slave\win\build\src\chrome\app\chrome_exe_main_win.cc @ 47]
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - 
0012ffc0 7c7e7077 chrome!__tmainCRTStartup+0x112 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 263]
WARNING: Stack unwind information not available. Following frames may be wrong.
0012fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49
87176_extended_stacktraces.txt
5.9 KB View Download
87176_extended_stacktraces_2.txt
32.7 KB View Download
The attached stacktrace is the first (0-ptr) exception I generated while trying to reproduce with the debugger attached. The other stacktraces are more breakpoint-related.

I used 14.0.811.0 (91452).

I am (however) not completely sure that this is the same bug. 


87176_exception_extended_stacktrace.txt
2.9 KB View Download
This issue has now been merged into the official v13 build (13.0.782.107).
I can see that this bug is very difficult to catch. However, this tab crash differs from other tab crashes. After some testing, I found the following.

1. I cannot click on (Aw, Snap!) "Learn More", because the link is not recognized
2. Sometimes when I open a lot of tabs, they load into each others address space (related, or cause of the crash).
3. This bug was introduced with version 13 (but I don't know which version precisely). 
WHY THE HELL do Google NOTHING? This Bug is sooo annoying?
Because it is very difficult to get the right stack trace. Can you reproduce the (child-process) crash in the debugger, or get a crash ID? That would help a lot!
Reproducible in Chrome 13.0.782.220 m on Windows Vista SP1 x64.
 Issue 95377  has been merged into this issue.

Comment 33 by ricow@google.com, Sep 21 2011

 Issue 96781  has been merged into this issue.
Labels: -OS-Windows -OS-Mac OS-All
I've been able to reproduce this crash as well, though I haven't been able to catch it in a debugger.  Useful repro steps for me (on Linux) are hitting Ctrl+N, Ctrl+H (to open history), and Ctrl+T in fairly quick succession.

I've noticed that the crash only seems to occur if no other New Tab Pages are open.  This makes me suspect that the crash happens because the first NTP (before starting to load the slow page) is starting to exit the process, just as the second NTP (in the new tab where we see Aw Snap) tries to join the process.  (All NTPs load in the same process, but it's free to exit if the last NTP closes.  That means there's a potential race.)

Can others confirm that this bug goes away if you have another New Tab Page lying around?  In that case, the NTP process wouldn't be trying to exit just as we create a new tab.
Cc: achuith@chromium.org
Here's a much easier way to reproduce, assuming it's the same issue:
1) Start Chrome with an NTP.
2) Attach a debugger to the NTP process and set a breakpoint in ChildProcess::ReleaseProcess.
3) Navigate the tab to any page (e.g., google.com).  The breakpoint will hit, but just let it sit there for the moment.
4) Open a new tab.  It will try to load in the halted NTP process.
5) Resume the NTP process.  Sad tab.

This sounds like the same bug Achuith was debugging on Chrome OS: http://code.google.com/p/chromium-os/issues/detail?id=18390 (http://codereview.chromium.org/7864019/).  I'm not sure why that fix isn't helping here, but perhaps I can investigate.
> Can others confirm that this bug goes away if you have another New Tab Page lying around?  In that case, the NTP process wouldn't be trying to exit just as we create a new tab.

Confirmed
Cc: ager@chromium.org
Owner: creis@chromium.org
Great.  I think we should be able to fix this similarly to the code we use for going back to a swapped out NavigationEntry (using ShutdownRequest).  I'll see if I can come up with a fix.

Comment 38 by creis@chromium.org, Nov 10 2011

Cc: jam@chromium.org
Hmm, this is trickier than the swapped out RenderViewHost case, where it's easy to decide not to use a swapped out RVH if we know it's exiting.

Currently, when the renderer process's ref_count_ gets to 0, it sends a ShutdownRequest message to the browser.  If the browser knows it doesn't need the renderer any more, it sends a Shutdown message in reply.  The renderer then finishes the tasks on its message loop and exits, and the browser finally hears about it in ProcessDied.

One case in this bug is easy: if the browser process knows that a navigation has recently started, it can deny the ShutdownRequest and keep the renderer around.  We already have RPH::pending_views_ for this purpose.

The other case is tricky: if the browser process has already send the Shutdown message to the renderer, there's still a period of time before ProcessDied.  If we try to navigate during that time, we should be creating a new renderer process for it.  However, we don't want to prematurely disconnect from the previous renderer process, because it might still send important messages as it finishes its message loop.  And we can't wait around for the old process to exit, without making the navigation logic even more asynchronous.

John, do you have a sense for whether we can just ignore the rest of the old process's messages?  Maybe we should just forcibly kill it and move on with the new navigation in this case?

Comment 39 by creis@chromium.org, Nov 10 2011

Cc: creis@chromium.org
 Issue 93352  has been merged into this issue.

Comment 40 by creis@chromium.org, Mar 20 2012

Status: Started
I finally had some time to get back to this and investigate further.

First, it took quite a bit of effort to verify, but it turns out that the tricky case in comment 38 isn't actually a problem.  The browser process is already eager about detaching from the renderer process when Shutdown is called, so it's safe to start a new navigation before the ProcessDied event.  More specifically, RPH::OnShutdownRequest fires a RENDERER_PROCESS_CLOSING notification, which synchronously causes RenderViewHostManager::RendererProcessClosing to delete any swapped out RenderViewHosts in the process.  This causes RPH::Cleanup to be called, which disconnects from the process.  That means it's safe to immediately start a new navigation to an NTP and it will end up in a new process.  Whew.

The easy case turns out to be even simpler-- we can just check the size of the render_widget_hosts_ map in OnShutdownRequest.  I have a CL up for review.  Still looking for a way to add a regression test.
Project Member

Comment 41 by bugdroid1@chromium.org, Mar 22 2012

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

------------------------------------------------------------------------
r128274 | creis@chromium.org | Thu Mar 22 12:50:51 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_process_host_impl.cc?r1=128274&r2=128273&pathrev=128274

Don't allow a renderer to exit if we are using it in other views.

BUG= 87176 
TEST=See bug, comment 35.


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

Comment 42 by websh...@gmail.com, Mar 22 2012

This Bug is unfixable, or? 

Comment 43 by creis@chromium.org, Mar 22 2012

Status: Fixed
Fixed in revision 128274.

Comment 44 by creis@chromium.org, Mar 23 2012

Cc: kareng@google.com
Labels: Mstone-18 Merge-Requested

Comment 45 by kareng@google.com, Mar 23 2012

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 46 by bugdroid1@chromium.org, Mar 23 2012

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

------------------------------------------------------------------------
r128563 | creis@chromium.org | Fri Mar 23 13:04:26 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1025/src/content/browser/renderer_host/render_process_host_impl.cc?r1=128563&r2=128562&pathrev=128563

Merge 128274 - Don't allow a renderer to exit if we are using it in other views.

BUG= 87176 
TEST=See bug, comment 35.


Review URL: http://codereview.chromium.org/9751001

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

Comment 47 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 48 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Feature-Navigation -Mstone-18 Cr-UI M-18 Cr-UI-Browser-Navigation
Project Member

Comment 49 by bugdroid1@chromium.org, Mar 13 2013

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

Sign in to add a comment