================test.js================== function f0(a1, a2, a3) { return a2; } const v6 = new Float32Array(1073741824); v6; v6.sort(f0); ========================================= Run Args: ./jsc --useConcurrentJIT=0 test.js Hello, my Fuzzer found a crash in the latest JavaScriptCore. BackTrace: * thread #1, name = 'jsc', stop reason = signal SIGABRT * frame #0: 0x00007ffff5ad800b libc.so.6`raise + 203 frame #1: 0x00007ffff5ab7859 libc.so.6`abort + 299 frame #2: 0x0000000002266514 jsc`bool WTF::VectorBufferBase<float, WTF::FastMalloc>::allocateBuffer<(this=0x00007fffffffc970, newCapacity=1073741824)0>(unsigned long) at Vector.h:314:17 frame #3: 0x00000000038ec090 jsc`bool WTF::VectorBuffer<float, 16ul, WTF::FastMalloc>::allocateBuffer<(this=0x00007fffffffc970, newCapacity=1073741824)0>(unsigned long) at Vector.h:506:35 frame #4: 0x00000000038ebf6e jsc`bool WTF::Vector<float, 16ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>::reserveCapacity<(this=0x00007fffffffc970, newCapacity=1073741824)0>(unsigned long) at Vector.h:1343:35 frame #5: 0x00000000038ebecd jsc`bool WTF::Vector<float, 16ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>::expandCapacity<(this=0x00007fffffffc970, newMinCapacity=1073741824)0>(unsigned long) at Vector.h:1199:12 frame #6: 0x00000000038ea6e5 jsc`WTF::Vector<float, 16ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>::resize(this=0x00007fffffffc970, size=1073741824) at Vector.h:1248:13 frame #7: 0x00000000038e9c68 jsc`long JSC::genericTypedArrayViewProtoFuncSortImpl<JSC::JSGenericTypedArrayView<JSC::Float32Adaptor> >(vm=0x00007fffaa000000, globalObject=0x00007fffaa41a068, thisObject=0x00007fffec009548, comparatorValue=JSValue @ 0x00007fffffffca80) at JSGenericTypedArrayViewPrototypeFunctions.h:784:9 frame #8: 0x00000000038da5ce jsc`long JSC::genericTypedArrayViewProtoFuncSort<JSC::JSGenericTypedArrayView<JSC::Float32Adaptor> >(vm=0x00007fffaa000000, globalObject=0x00007fffaa41a068, callFrame=0x00007fffffffccb0) at JSGenericTypedArrayViewPrototypeFunctions.h:877:5 frame #9: 0x00000000038cac32 jsc`JSC::typedArrayViewProtoFuncSort(globalObject=0x00007fffaa41a068, callFrame=0x00007fffffffccb0) at JSTypedArrayViewPrototype.cpp:256:5 frame #10: 0x00007fffab1901b8 frame #11: 0x0000000001a9bbe8 jsc`js_trampoline_op_call + 23 frame #12: 0x0000000001a7730b jsc`vmEntryToJavaScript + 266 frame #13: 0x0000000003097c9a jsc`JSC::Interpreter::executeProgram(this=0x00007fffaa012750, source=0x00007fffffffd978, (null)=0x00007fffaa41a068, thisObj=0x00007fffec0001e8) at Interpreter.cpp:1082:28 frame #14: 0x000000000355835a jsc`JSC::evaluate(globalObject=0x00007fffaa41a068, source=0x00007fffffffd978, thisValue=JSValue @ 0x00007fffffffd870, returnedException=0x00007fffffffd998) at Completion.cpp:137:37 frame #15: 0x0000000001730602 jsc`runWithOptions(globalObject=0x00007fffaa41a068, options=0x000000000576b918, success=0x00007fffffffde23) at jsc.cpp:3941:35 frame #16: 0x00000000016d2c4a jsc`jscmain(this=0x00007fffffffdf00, vm=0x00007fffaa000000, globalObject=0x00007fffaa41a068, success=0x00007fffffffde23)::$_9::operator()(JSC::VM&, GlobalObject*, bool&) const at jsc.cpp:4581:13 frame #17: 0x0000000001691d9e jsc`int runJSC<jscmain(int, char**)::$_9>(options=0x000000000576b918, isWorker=false, func=0x00007fffffffdf00)::$_9 const&) at jsc.cpp:4374:9 frame #18: 0x000000000168f5f0 jsc`jscmain(argc=3, argv=0x00007fffffffe078) at jsc.cpp:4574:18 frame #19: 0x000000000168f256 jsc`main(argc=3, argv=0x00007fffffffe078) at jsc.cpp:3703:15 frame #20: 0x00007ffff5ab9083 libc.so.6`__libc_start_main + 243 frame #21: 0x000000000165712e jsc`_start + 46
This seems like expected behavior, crashing when memory allocation fails?
<rdar://problem/118924292>
Are you sure this is expected behavior? I found this bug has been fixed by Mark Lam in https://bugs.webkit.org/show_bug.cgi?id=265743. Why is the status of my bug not updated. This is a bug I reported. I want to know if my bug has been fixed. This bug should be assigned, shouldn't it？
I have reported 27 bugs related to webkit. I found some bugs like 244182, 244183, 244187, 244193, 248023, 255838, 255839 have been fixed. But these bugs have not been assigned. I feel confused. The status of the bug is important to me. I want to know if my bugs I found have been fixed. However, you fixed the bug in another bugID and ignored my bugs. Is this behavior normal? https://bugs.webkit.org/show_bug.cgi?id=244182 https://bugs.webkit.org/show_bug.cgi?id=244183 https://bugs.webkit.org/show_bug.cgi?id=244187 https://bugs.webkit.org/show_bug.cgi?id=244193 https://bugs.webkit.org/show_bug.cgi?id=248023 https://bugs.webkit.org/show_bug.cgi?id=255838 https://bugs.webkit.org/show_bug.cgi?id=255839
> Are you sure this is expected behavior? I found this bug has been fixed by Mark Lam in https://bugs.webkit.org/show_bug.cgi?id=265743. Why is the status of my bug not updated. This is a bug I reported. I want to know if my bug has been fixed. This bug should be assigned, shouldn't it？ Thanks for filing this bug. This does appear to be expected behavior. Reasonable programs would not be trying to allocated a Float32Array with the a size as large as 1073741824. We have 2 ways to handle a request like this: 1. Crash because the request is too large and unreasonable for a realistic program. 2. Detect it and throw an OutOfMemory error. (1) is our default approach, because it is always correct and it does not impact users in real world usage, except for pathological websites. Even if we throw an OOME, the website would to work correctly anyway. It will just error out. This is a website specific bug, not a browser bug. (2) is a "nice to have" polish if we can fix this add an OOME check without too much performance and complexity cost. Regardless, even when possible, it is low priority to implement (2). Also, IIUC, bugs are not assigned to WebKit developers by default. This is an open project, and developers who want to take on a bug may assign it to themselves to tackle and to let others know that they are working on it so as to avoid redundant work.
(In reply to EntryHi from comment #4) > I have reported 27 bugs related to webkit. I found some bugs like 244182, > 244183, 244187, 244193, 248023, 255838, 255839 have been fixed. But these > bugs have not been assigned. I feel confused. The status of the bug is > important to me. I want to know if my bugs I found have been fixed. However, > you fixed the bug in another bugID and ignored my bugs. Is this behavior > normal? > > > https://bugs.webkit.org/show_bug.cgi?id=244182 > https://bugs.webkit.org/show_bug.cgi?id=244183 > https://bugs.webkit.org/show_bug.cgi?id=244187 > https://bugs.webkit.org/show_bug.cgi?id=244193 > https://bugs.webkit.org/show_bug.cgi?id=248023 > https://bugs.webkit.org/show_bug.cgi?id=255838 > https://bugs.webkit.org/show_bug.cgi?id=255839 Thanks for bring my attention to these. We'll take a look.
(In reply to Mark Lam from comment #5) > > Are you sure this is expected behavior? I found this bug has been fixed by Mark Lam in https://bugs.webkit.org/show_bug.cgi?id=265743. Why is the status of my bug not updated. This is a bug I reported. I want to know if my bug has been fixed. This bug should be assigned, shouldn't it？ > > Thanks for filing this bug. > > This does appear to be expected behavior. Reasonable programs would not be > trying to allocated a Float32Array with the a size as large as 1073741824. > We have 2 ways to handle a request like this: > 1. Crash because the request is too large and unreasonable for a realistic > program. > 2. Detect it and throw an OutOfMemory error. > > (1) is our default approach, because it is always correct and it does not > impact users in real world usage, except for pathological websites. Even if > we throw an OOME, the website would to work correctly anyway. It will just > error out. This is a website specific bug, not a browser bug. > > (2) is a "nice to have" polish if we can fix this add an OOME check without > too much performance and complexity cost. Regardless, even when possible, > it is low priority to implement (2). > > Also, IIUC, bugs are not assigned to WebKit developers by default. This is > an open project, and developers who want to take on a bug may assign it to > themselves to tackle and to let others know that they are working on it so > as to avoid redundant work. Thanks for your reply. So, the bug I reported has been fixed, but the status here is still 'New', not 'Fixed', right? That seems odd to me.