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

Issue 870234 link

Starred by 1 user
Status: Duplicate
Merged: issue 114520
Owner: ----
Closed: Aug 7
Cc:
etienneb@chromium.org
wfh@chromium.org
creis@chromium.org
chrisha@chromium.org
█ hpayer@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

A renderer consistently chews RAM then explodes upon session restore

Project Member Reported by grt@chromium.org, Aug 2 
I have a reliable renderer OOM upon session restore, but I'm not sure why. Basically, I launch Chrome and wait a minute or so and notice a renderer die. I've watched process private bytes in Process Hacker during this time, and I see one single renderer process grow and grow (>3GB) until it goes kablewie. A crash is not reported for this.

I grabbed a dump of the proc as it was growing, and see this stack on the main thread:

0:000> k
 # Child-SP          RetAddr           Call Site
00 000000a9`fcdfbfd0 00007ffe`c4b66073 chrome_child!v8::internal::Heap::RegisterExternallyReferencedObject+0x73 [C:\b\c\b\win64_clang\src\v8\src\heap\heap.cc @ 4853] 
01 000000a9`fcdfc020 00007ffe`c4e66e13 chrome_child!blink::ScriptWrappable::Trace+0x19 [C:\b\c\b\win64_clang\src\third_party\blink\renderer\platform\bindings\script_wrappable.cc @ 44] 
02 000000a9`fcdfc060 00007ffe`c66f0382 chrome_child!blink::CSSComputedStyleDeclaration::Trace+0x53 [C:\b\c\b\win64_clang\src\third_party\blink\renderer\core\css\css_computed_style_declaration.cc @ 533] 
03 000000a9`fcdfc0c0 00007ffe`c5953a5d chrome_child!blink::ScriptWrappableMarkingVisitor::AdvanceTracing+0xe8 [C:\b\c\b\win64_clang\src\third_party\blink\renderer\platform\bindings\script_wrappable_marking_visitor.cc @ 196] 
04 000000a9`fcdfc150 00007ffe`c595337c chrome_child!v8::internal::MarkCompactCollector::PerformWrapperTracing+0x17d [C:\b\c\b\win64_clang\src\v8\src\heap\mark-compact.cc @ 1640] 
05 000000a9`fcdfc280 00007ffe`c5957f9e chrome_child!v8::internal::MarkCompactCollector::ProcessEphemeronsUntilFixpoint+0x3c [C:\b\c\b\win64_clang\src\v8\src\heap\mark-compact.cc @ 1479] 
06 000000a9`fcdfc3f0 00007ffe`c5950726 chrome_child!v8::internal::MarkCompactCollector::ProcessEphemeronMarking+0x1e [C:\b\c\b\win64_clang\src\v8\src\heap\mark-compact.cc @ 1692] 
07 000000a9`fcdfc420 00007ffe`c594fcf6 chrome_child!v8::internal::MarkCompactCollector::MarkLiveObjects+0x956 [C:\b\c\b\win64_clang\src\v8\src\heap\mark-compact.cc @ 1795] 
08 000000a9`fcdfc6a0 00007ffe`c5936cc1 chrome_child!v8::internal::MarkCompactCollector::CollectGarbage+0x76 [C:\b\c\b\win64_clang\src\v8\src\heap\mark-compact.cc @ 462] 
09 000000a9`fcdfc6f0 00007ffe`c4e92821 chrome_child!v8::internal::Heap::MarkCompact+0x101 [C:\b\c\b\win64_clang\src\v8\src\heap\heap.cc @ 1869] 
0a 000000a9`fcdfc770 00007ffe`c4e90b99 chrome_child!v8::internal::Heap::PerformGarbageCollection+0x611 [C:\b\c\b\win64_clang\src\v8\src\heap\heap.cc @ 1720] 
0b 000000a9`fcdfc930 00007ffe`c59352ff chrome_child!v8::internal::Heap::CollectGarbage+0x599 [C:\b\c\b\win64_clang\src\v8\src\heap\heap.cc @ 1355] 
0c 000000a9`fcdfca70 00007ffe`c59120f1 chrome_child!v8::internal::Heap::HandleGCRequest+0xaf [C:\b\c\b\win64_clang\src\v8\src\heap\heap.cc @ 1069] 
0d 000000a9`fcdfcaa0 00007ffe`c5a7fc70 chrome_child!v8::internal::StackGuard::HandleInterrupts+0x91 [C:\b\c\b\win64_clang\src\v8\src\execution.cc @ 517] 
0e 000000a9`fcdfcaf0 00007ffe`c5cbdc32 chrome_child!v8::internal::Runtime_StackGuard+0x50 [C:\b\c\b\win64_clang\src\v8\src\runtime\runtime-internal.cc @ 255] 
0f 000000a9`fcdfcb40 00007ffe`c5ccf96d chrome_child!v8::internal::NativesCollection<v8::internal::EXPERIMENTAL_EXTRAS>::GetScriptName+0x94932
10 000000a9`fcdfcb48 00007ffe`c5ccf96d chrome_child!v8::internal::NativesCollection<v8::internal::EXPERIMENTAL_EXTRAS>::GetScriptName+0xa666d
11 000000a9`fcdfcb50 00006319`f04895c1 chrome_child!v8::internal::NativesCollection<v8::internal::EXPERIMENTAL_EXTRAS>::GetScriptName+0xa666d
12 000000a9`fcdfcb58 00003597`bcd112f1 0x00006319`f04895c1
13 000000a9`fcdfcb60 00000000`00000421 0x00003597`bcd112f1
14 000000a9`fcdfcb68 000033c5`98d37259 0x421
15 000000a9`fcdfcb70 000045ee`5fd99241 0x000033c5`98d37259
16 000000a9`fcdfcb78 000000a9`fcdfcb40 0x000045ee`5fd99241
17 000000a9`fcdfcb80 00000000`00000006 0x000000a9`fcdfcb40
18 000000a9`fcdfcb88 000000a9`fcdfcc10 0x6
19 000000a9`fcdfcb90 000045ee`600d7789 0x000000a9`fcdfcc10
1a 000000a9`fcdfcb98 00000000`00000000 0x000045ee`600d7789

I'd be happy to help diagnose, but I'm not sure where to go from here. Hoping this rings a bell for you V8 folks. I'm also not sure if it's a particular site I happen to have loaded in a tab. I never have a problem reloading tabs that are sad after this happens.

Comment 1 by grt@chromium.org, Aug 2

Cc: etiennep@chromium.org chrisha@chromium.org

Comment 2 by grt@chromium.org, Aug 2

Cc: -etiennep@chromium.org etienneb@chromium.org

Comment 3 by wfh@chromium.org, Aug 2 

crash probably not reported because it hits the sandbox memory limit - you can confirm by looking for CrashExitCodes.Renderer and seeing an entry in the 7012 bucket (SBOX_FATAL_MEMORY_EXCEEDED).

it would be nice if v8 were to crash with oom before this hit, then we'd get crash reports.

Comment 4 by grt@chromium.org, Aug 3 

Yup, 7012 is the one. I'll try connecting to the process with windbg as it grows to see if it breaks into the debugger on the allocation that tips it over. I wonder if that will be educational.

Comment 5 by grt@chromium.org, Aug 4 

This might just be a simple case of bad memory management by some web app. I see that there are 47 tabs running in this one renderer (that's just how I roll). But then again, why are we shoving so many into one process?

Comment 6 by chrisha@chromium.org, Aug 6

Cc: creis@chromium.org
Regarding the "shoving so many into one process", maybe creis@ and isolation folks can comment about that particular logic?

Comment 7 by creis@chromium.org, Aug 6

Components: Internals>Sandbox>SiteIsolation
There's a few reasons many tabs might end up in the same process.

Do you happen to have multiple profiles open when you restore?  That would be the most likely, since one profile can eat up the whole process limit and leave only one process for the other profile(s).  There's an ancient bug on that in issue 114520, but it's a tricky one to solve.

Otherwise, it could happen if you have sufficiently many tabs to go over the limit and force all additional same-site tabs into the same process (or a set of same-site processes), assuming Site Isolation is enabled.  Chrome will also aggressively look for existing same-site processes to put OOPIFs into, to keep the process count low.

Curious if any of those apply, and if not, we can look for other reasons.

Comment 8 by grt@chromium.org, Aug 7 

Yes, I typically have 2-4 profiles restoring at the same time. I also have A LOT of tabs open. :-) This is on my corp machine, so I would assume that Site Isolation is enabled.

Is there any reasonable action to be taken here?

Comment 9 by creis@chromium.org, Aug 7

Mergedinto: 114520
Status: Duplicate (was: Untriaged)
Sounds like it's the multi-profile thing.  Other than finding a fix for issue 114520, you can run with --renderer-process-limit=N, for some large enough N to handle the tabs (etc) from all your profiles.
►

Sign in to add a comment