Crash chrome on Demand (Memory exhaustion)
Reported by
raj.si...@gmail.com,
Sep 7 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Navigate to http://demos.telerik.com/kendo-ui/slider/index 2. Click on Edit this example 3. Press Ctrl Enter to see the slider 4. In the source on the left change the max value to a number greated than MAX INT (i.e 999999999999999999999) 5. Press Ctrl Enter 6. Aw, Snap!!! What is the expected behavior? For chrome to not crash. What went wrong? Aww snap tab crash Did this work before? N/A Chrome version: 52.0.2743.116 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0 Debugging a chrome build gives this stack: KernelBase.dll!RaiseException () Unknown blink_core.dll!blink::reportOOMErrorInMainThread(const char * location, bool isJsHeap) Line 103 C++ v8.dll!v8::Utils::ReportOOMFailure(const char * location, bool is_heap_oom) Line 365 C++ v8.dll!v8::internal::V8::FatalProcessOutOfMemory(const char * location, bool is_heap_oom) Line 327 C++ v8.dll!v8::internal::Heap::AllocateUninitializedFixedDoubleArray(int length, v8::internal::PretenureFlag pretenure) Line 3977 C++ v8.dll!v8::internal::Factory::NewFixedDoubleArray(int size, v8::internal::PretenureFlag pretenure) Line 155 C++ v8.dll!v8::internal::`anonymous namespace'::ElementsAccessorBase<v8::internal::`anonymous namespace'::FastPackedDoubleElementsAccessor,v8::internal::A0xd62c7cea::ElementsKindTraits<4> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject> object, unsigned int index) Line 925 C++ v8.dll!v8::internal::__RT_impl_Runtime_GrowArrayElements(v8::internal::Arguments args, v8::internal::Isolate * isolate) Line 378 C++ > v8.dll!v8::internal::Runtime_GrowArrayElements(int args_length, v8::internal::Object * * args_object, v8::internal::Isolate * isolate) Line 364 C++ 00000082c4d063ab() Unknown v8.dll!v8::internal::Runtime_GrowArrayElements(int args_length, v8::internal::Object * * args_object, v8::internal::Isolate * isolate) Line 364 C++ 00000020f02ab8c1() Unknown cdcdcdcd00000000() Unknown cdcdcdcdcdcdcdcd() Unknown cdcdcdcdcdcdcdcd() Unknown cdcdcdcdcdcdcdcd() Unknown 00000082c4d062e1() Unknown 0000002abdaf9c30() Unknown 0000000300000000() Unknown 0000002abdaf9cc0() Unknown 00000082c5dcf00e() Unknown 02c90fff00000000() Unknown 000000876eaaa981() Unknown 408f400000000000() Unknown 3e00000000200000() Unknown 00000082c4d08361() Unknown 000000876eaaa981() Unknown 0000000a00000000() Unknown 0000002abdaf9e00() Unknown 00000082c5dcf980() Unknown 0000002abdaf9d80() Unknown v8.dll!v8::internal::Runtime_CompileForOnStackReplacement(int args_length, v8::internal::Object * * args_object, v8::internal::Isolate * isolate) Line 287 C++ 00000020f02ab8c1() Unknown 000000876eaaa9a1() Unknown 000000876eaaa981() Unknown 000000876eaaaa01() Unknown We have had intermittent crashes for a few weeks and this is one that is different but hope the underlying cause is related. Please fix asap.
,
Sep 7 2016
OK after debugging it turns out this is quite easily reproducible in dev tools with a very large number, from an external script looping to MAXINT is enough.
var testArray = [];
for (var i=0; i<999999999999999999999999999999; i++) {
testArray[i] = 0;
}
Somehow the array indexing isn't checking bounds correctly.
Works in FireFox.
,
Sep 7 2016
and IE
,
Sep 7 2016
As alluded to in the stack trace, the render process is dying because it runs out of memory. In a 32bit process, you typically only have about ~300mb of contiguous address space available, so if your code depends on an allocation requiring a larger block of memory, it will fail. If you run on 64bit, the address space is considerably larger, although Chrome's job objects do enforce a 4gb allocation limit on the process as a whole. As far as I know, this is working as intended; see also https://bugs.chromium.org/p/chromium/issues/detail?id=640712
,
Sep 8 2016
But isn't there a case of chrome not actually crashing a tab under any circumstances from javascript? Shouldn't it at least refuse to try and allocate the memory and return an error instead to the javascript? Just playing devils advocate.
,
Sep 8 2016
OK I just read the link. I still think it shouldn't crash, but I understand there's a technical reason why it does. What i've done in the past in situations like this is check how much memory is actually available before assigning it and either refusing to if there isn't enough and returning an error, or assign a lower amount (not applicable in this case).
,
Sep 8 2016
As already mentioned, this is working as intended. Closing this bug. |
|||
►
Sign in to add a comment |
|||
Comment 1 by raj.si...@gmail.com
, Sep 7 2016In case it helps on my local debug build of chrome these are last few lines of the output window: <--- Last few GCs ---> [23372:0000016DB0E70580] 301769 ms: Mark-sweep 92.1 (99.8) -> 85.5 (96.3) MB, 6.9 / 4.6 ms (+ 42.7 ms in 5 steps since start of marking, biggest step 23.0 ms, walltime since start of marking 98 ms) GC interrupt GC in old space requested [23372:0000016DB0E70580] 301949 ms: Mark-sweep 339.8 (350.7) -> 282.6 (293.5) MB, 5.6 / 4.6 ms (+ 40.8 ms in 3 steps since start of marking, biggest step 40.7 ms, walltime since start of marking 168 ms) GC interrupt GC in old space requested <--- JS stacktrace ---> ==== JS stack trace ========================================= Security context: 000003CB1DE1E519 <String[21]: http://localhost:7900> 2: _calculateItemsWidth [http://localhost:7900/apps/pandora/js/lib/kendo.all.js:~40974] [pc=00000082C5DCF980](this=000000876EAAA9A1 <a init with map 000003ED2848D9A9>,itemsCount=2147483647) 3: _sliderItemsInit [http://localhost:7900/apps/pandora/js/lib/kendo.all.js:40868] [pc=00000082C5DCDF74](this=000000876EAAA9A1 <a init with map 000003ED2848D9A9>) 4: ini... Exception thrown at 0x00007FFDF6411F28 (KernelBase.dll) in chrome.exe: 0xE0000008. Unhandled exception at 0x00007FFDF6411F28 (KernelBase.dll) in chrome.exe: 0xE0000008.