Issue metadata
Sign in to add a comment
|
CHECK failure: size <= kMaxRegularHeapObjectSize in runtime-internal.cc |
||||||||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5458811845607424 Fuzzer: v8_builtins_generator Job Type: linux_msan_d8 Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: size <= kMaxRegularHeapObjectSize in runtime-internal.cc Sanitizer: memory (MSAN) Regressed: https://clusterfuzz.com/revisions?job=linux_msan_d8&range=49342:49343 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5458811845607424 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 14 2017
Removing the owner so V8 sheriff can triage that.
,
Nov 14 2017
Assigning to reviewer and moving author to cc.
,
Nov 14 2017
My bad, I missed that during review. We need to pass kAllowLargeObjectAllocation to CSA::AllocateJSObjectFromMap. Peter, want to take care of this?
,
Nov 15 2017
,
Nov 15 2017
,
Nov 15 2017
Correction: The culprit call isn't AllocateJSObjectFromMap but AllocateFixedArray (that makes more sense). Got a fix in flight.
,
Nov 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/271ffdb0f7b780f2df61202398fdc0e435e04102 commit 271ffdb0f7b780f2df61202398fdc0e435e04102 Author: Jakob Gruber <jgruber@chromium.org> Date: Wed Nov 15 12:08:35 2017 [collections] Allocate large collections in large object space The backing store fixed array for collections needs to be allocated in LOS if it exceeds the maximum regular heap object size. Drive-by-fix: Only store fixed array map once as per TODO. Bug: chromium:784862 Change-Id: I6b4dd2e45153ae107171e21bc7448e0d9b54b0ed Reviewed-on: https://chromium-review.googlesource.com/771150 Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49378} [modify] https://crrev.com/271ffdb0f7b780f2df61202398fdc0e435e04102/src/builtins/builtins-collections-gen.cc [modify] https://crrev.com/271ffdb0f7b780f2df61202398fdc0e435e04102/src/code-stub-assembler.cc [modify] https://crrev.com/271ffdb0f7b780f2df61202398fdc0e435e04102/src/debug/debug-evaluate.cc [add] https://crrev.com/271ffdb0f7b780f2df61202398fdc0e435e04102/test/mjsunit/regress/regress-784862.js
,
Nov 15 2017
,
Nov 15 2017
,
Nov 16 2017
ClusterFuzz has detected this issue as fixed in range 49377:49378. Detailed report: https://clusterfuzz.com/testcase?key=5458811845607424 Fuzzer: v8_builtins_generator Job Type: linux_msan_d8 Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: size <= kMaxRegularHeapObjectSize in runtime-internal.cc Sanitizer: memory (MSAN) Regressed: https://clusterfuzz.com/revisions?job=linux_msan_d8&range=49342:49343 Fixed: https://clusterfuzz.com/revisions?job=linux_msan_d8&range=49377:49378 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5458811845607424 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.
,
Nov 16 2017
ClusterFuzz testcase 5458811845607424 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Feb 21 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 27 2018
,
Jul 28
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ClusterFuzz
, Nov 14 2017Owner: peter.wm...@gmail.com
Status: Assigned (was: Untriaged)