New issue
Advanced search Search tips

Issue 601621 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Nov 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Sanitizer CHECK failure in CHECK failed: ((0)) != (0) (0, 0)

Project Member Reported by ClusterFuzz, Apr 7 2016

Issue description

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4587716106256384

Fuzzer: mbarbella_js_mutation
Job Type: linux_msan_d8
Platform Id: linux

Crash Type: Sanitizer CHECK failure
Crash Address: 
Crash State:
  CHECK failed: ((0)) != (0) (0, 0)
  

Minimized Testcase (0.07 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv94yK7hiQUbhcTuf7GPhzLW20wLmvx9FJxF5adurLEMmMvOfO6JKsAuYOcronlkeOWtMZWSrQE2KI4LtzYaWnY0-Cs25lPnrNCrTuPPYagPq9gA02FUis-BE3LChKLwlrHWfmpFIZelbyhFuf_8kYtK1kb7-vw
(function __f_7() {
})();
__v_12 = new ArrayBuffer(1073741824 * 65535);


Filer: manoranjanr

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
 
Labels: Te-Logged
We should really (a) build sanitizer runtime libraries with debug info and (b) print stack trace for this error.

For now,

Catchpoint 1 (call to syscall exit_group), 0x000000000042814b in __sanitizer::internal__exit(int) ()
(gdb) bt
#0  0x000000000042814b in __sanitizer::internal__exit(int) ()
#1  0x0000000000423340 in __sanitizer::Die() ()
#2  0x00000000004235f3 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ()
#3  0x0000000000421e24 in __sanitizer::ReportAllocatorCannotReturnNull() ()
#4  0x000000000043cb1a in __msan::MsanAllocate(__sanitizer::StackTrace*, unsigned long, unsigned long, bool) ()
#5  0x0000000000446246 in malloc ()
#6  0x00000000004baea5 in v8::(anonymous namespace)::ShellArrayBufferAllocator::Allocate(unsigned long) ()
    at ../../v8/src/d8.cc:79
#7  0x0000000001adf27c in SetupAllocatingData () at ../../v8/src/objects.cc:19566
#8  0x00000000006fec33 in Builtin_Impl_ArrayBufferConstructor_ConstructStub () at ../../v8/src/builtins.cc:4091
#9  0x000000000069578a in Builtin_ArrayBufferConstructor_ConstructStub () at ../../v8/src/builtins.cc:4065
#10 0x000000000281a92b in DoRuntimeCall () at ../../v8/src/arm64/simulator-arm64.cc:610
#11 0x000000000281780b in ExecuteInstruction () at ../../v8/src/arm64/simulator-arm64.h:315
#12 Run () at ../../v8/src/arm64/simulator-arm64.cc:446
#13 CheckPCSComplianceAndRun () at ../../v8/src/arm64/simulator-arm64.cc:252
#14 CallVoid () at ../../v8/src/arm64/simulator-arm64.cc:162
#15 0x0000000002818235 in CallInt64 () at ../../v8/src/arm64/simulator-arm64.cc:169
#16 CallJS () at ../../v8/src/arm64/simulator-arm64.cc:194
#17 0x0000000001461fd1 in Invoke () at ../../v8/src/execution.cc:97
#18 0x0000000001460af4 in Call () at ../../v8/src/execution.cc:163
#19 0x00000000005175f6 in Run () at ../../v8/src/api.cc:1792
#20 0x000000000048b01b in ExecuteString () at ../../v8/src/d8.cc:390
#21 0x00000000004a45aa in Execute () at ../../v8/src/d8.cc:1504
#22 0x00000000004aa74a in RunMain () at ../../v8/src/d8.cc:2006
#23 0x00000000004b6252 in Main () at ../../v8/src/d8.cc:2470
#24 0x00000000004b9f59 in main () at ../../v8/src/d8.cc:2505

Components: Blink>JavaScript
Status: Untriaged (was: Available)
Labels: -Pri-1 Pri-2
The test tries to allocate 64Tb buffer, I guess malloc just can't do that.
Status: Available (was: Untriaged)
Project Member

Comment 6 by sheriffbot@chromium.org, Nov 22 2016

Labels: -Restrict-View-EditIssue
Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: -Blink>JavaScript
Status: Archived (was: Available)
Nothing actionable from the V8 side.

The interface of {v8::ArrayBuffer::Allocator} explicitly allows NULL to be returned by the underlying implementation and V8 should handle those cases gracefully. If the underlying implementation decides to hard-crash and kill the process then that would also be a "safe" implementation. Directly mapping it to {malloc} is OK from V8's point of view.

Feel free to re-open in case there is something actionable outside of V8 (already removed the "Blink>JavaScript" component to remove it from the V8 queue).

Sign in to add a comment