New issue
Advanced search Search tips

Issue 853602 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

CHECK failure: count <= MaxElementCountInBackingStore<T>() in partition_allocator.h

Project Member Reported by ClusterFuzz, Jun 18 2018

Issue description

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)

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4960496877568000

Issue filed automatically.

See https://github.com/google/clusterfuzz-tools for more information.
 
Project Member

Comment 1 by ClusterFuzz, Jun 18 2018

Components: Blink>Internals>WTF
Labels: Test-Predator-Auto-Components
Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Comment 2 by yutak@chromium.org, Jun 18 2018

Components: -Blink>Internals>WTF Blink>Network>XHR
Labels: -Pri-1 Pri-3

Comment 3 by ricea@chromium.org, 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.

Comment 4 by ricea@chromium.org, Jun 18 2018

Status: Available (was: Untriaged)
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.

Comment 5 by ricea@chromium.org, Jun 21 2018

Cc: ricea@chromium.org
Status: WontFix (was: Available)
Won't fix: crashing as intended.
Project Member

Comment 7 by ClusterFuzz, Aug 21

Labels: Needs-Feedback
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.
Project Member

Comment 8 by ClusterFuzz, 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