CHECK failure: count <= MaxElementCountInBackingStore<T>() in partition_allocator.h |
||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4960496877568000 Fuzzer: inferno_twister Job Type: linux_lsan_chrome_mp Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: count <= MaxElementCountInBackingStore<T>() in partition_allocator.h QuantizedSize<unsigned AllocationSize Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4960496877568000 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Jun 18 2018
,
Jun 18 2018
Slightly cleaned-up of the repro:
<script>
var n = -2147483648;
var obj = {};
try {
for (var i = 8; n < -1073741825; ++xhr)
obj += obj;
} catch(e) {; }
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://localhost:8000/xmlhttprequest/resources/cross-site-__f_4-events.cgi?allow");
xhr.send(obj);
</script>
It doesn't actually require a server to be running on localhost:8000.
,
Jun 18 2018
Here's a repro with the irrelevant parts removed:
"""
<script>
var obj = "abc"
try {
while (true)
obj += obj;
} catch(e) { }
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://test/");
xhr.send(obj);
</script>
"""
It's creates a 512MB string and then attempts to send it via XHR. The render process crashes because it tries to allocate >2GB of RAM to hold the UTF-8 encoded string.
Here's the render crash output:
[1:1:0618/182035.053009:FATAL:partition_allocator.h(37)] Check failed: count <= MaxElementCountInBackingStore<T>() (2415919104 vs. 2147487744)
#0 0x7f90e41dd8dc base::debug::StackTrace::StackTrace()
#1 0x7f90e41501c0 logging::LogMessage::~LogMessage()
#2 0x7f90d437bb58 WTF::PartitionAllocator::QuantizedSize<>()
#3 0x7f90d439dde1 WTF::TextCodecUTF8::EncodeCommon<>()
#4 0x7f90d439dd2e WTF::TextCodecUTF8::Encode()
#5 0x7f90d439e034 WTF::TextEncoding::Encode()
#6 0x7f90ddf0103e blink::XMLHttpRequest::send()
#7 0x7f90de087dab blink::V8XMLHttpRequest::sendMethodCallback()
#8 0x7f90de725f31 v8::internal::FunctionCallbackArguments::Call()
#9 0x7f90de725426 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#10 0x7f90de724b36 v8::internal::Builtin_Impl_HandleApiCall()
#11 0x7f90deeb8e8e <unknown>
Received signal 6
#0 0x7f90e41dd8dc base::debug::StackTrace::StackTrace()
#1 0x7f90e41dd441 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f90dada70c0 <unknown>
#3 0x7f90d8c3afcf gsignal
#4 0x7f90d8c3c3fa abort
#5 0x7f90e41dc295 base::debug::BreakDebugger()
#6 0x7f90e4150632 logging::LogMessage::~LogMessage()
#7 0x7f90d437bb58 WTF::PartitionAllocator::QuantizedSize<>()
#8 0x7f90d439dde1 WTF::TextCodecUTF8::EncodeCommon<>()
#9 0x7f90d439dd2e WTF::TextCodecUTF8::Encode()
#10 0x7f90d439e034 WTF::TextEncoding::Encode()
#11 0x7f90ddf0103e blink::XMLHttpRequest::send()
#12 0x7f90de087dab blink::V8XMLHttpRequest::sendMethodCallback()
#13 0x7f90de725f31 v8::internal::FunctionCallbackArguments::Call()
#14 0x7f90de725426 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#15 0x7f90de724b36 v8::internal::Builtin_Impl_HandleApiCall()
#16 0x7f90deeb8e8e <unknown>
r8: 0000000000000000 r9: 00007ffc24d07a10 r10: 0000000000000008 r11: 0000000000000246
r12: 00007ffc24d08110 r13: 000000000000008e r14: 00007ffc24d08118 r15: 00007ffc24d08120
di: 0000000000000002 si: 00007ffc24d07a10 bp: 00007ffc24d07c50 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007f90d8c3afcf sp: 00007ffc24d07a88
ip: 00007f90d8c3afcf efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
I think this is crashing as intended. Even if we don't crash here, we crash a bit later trying to send the encoded string via mojo.
,
Jun 21 2018
,
Aug 14
Won't fix: crashing as intended.
,
Aug 21
ClusterFuzz testcase 4960496877568000 is still reproducing on tip-of-tree build (trunk). If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase. Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.
,
Aug 23
ClusterFuzz has detected this issue as fixed in range 585109:585138. Detailed report: https://clusterfuzz.com/testcase?key=4960496877568000 Fuzzer: inferno_twister Job Type: linux_lsan_chrome_mp Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: count <= MaxElementCountInBackingStore<T>() in partition_allocator.h QuantizedSize<unsigned AllocationSize Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_lsan_chrome_mp&range=549059:549062 Fixed: https://clusterfuzz.com/revisions?job=linux_lsan_chrome_mp&range=585109:585138 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4960496877568000 See https://github.com/google/clusterfuzz-tools for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ClusterFuzz
, Jun 18 2018Labels: Test-Predator-Auto-Components