|
|
Description[cctest] Fix invalid assumption in test-unboxed-doubles
test-unboxed-doubles/WriteBarrierObjectShiftFieldsRight recently started
failing on arm64-nosnapshot builds due to a broken CHECK.
# Fatal error in ../../test/cctest/test-unboxed-doubles.cc, line 1417
# Check failed: heap->InNewSpace(*obj_value).
It expects the result of Factory::NewJSArray() to be in new
space; but NewJSArray encapsulates two allocations so the return value can
actually be in old space. Fix it by ensuring only one allocation occurs.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2759433002
Cr-Commit-Position: refs/heads/master@{#43886}
Committed: https://chromium.googlesource.com/v8/v8/+/ad75ded221595bbdc1ec72d087fe8aa22bddb17b
Patch Set 1 #
Total comments: 2
Patch Set 2 : Remove s390/ppc fixes (https://codereview.chromium.org/2757673004/) #Patch Set 3 : Alloc a HeapNumber instead #Messages
Total messages: 25 (19 generated)
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== [regexp] Fix build failures triggered by RegExpStub port The arm64-nosnapshot failure looks like a broken test caused by changes in memory layout. It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. ppc and s390 just had compilation issues. BUG= ========== to ========== [regexp] Fix build failures triggered by RegExpStub port The arm64-nosnapshot failure looks like a broken test caused by changes in memory layout. It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. ppc and s390 just had compilation issues. BUG=v8:5339 ==========
jgruber@chromium.org changed reviewers: + jkummerow@chromium.org
Fixes compilation failures on s390 and ppc, and a test failure on arm64. jkummerow@ PTAL at test-unboxed-doubles (git blame says you added this test a while back). https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%... https://codereview.chromium.org/2759433002/diff/1/test/cctest/test-unboxed-do... File test/cctest/test-unboxed-doubles.cc (left): https://codereview.chromium.org/2759433002/diff/1/test/cctest/test-unboxed-do... test/cctest/test-unboxed-doubles.cc:1414: obj_value = factory->NewJSArray(32 * KB, FAST_HOLEY_ELEMENTS); I don't think the capacity of 32*KB was significant for this test, but please double-check. https://codereview.chromium.org/2759433002/diff/1/test/cctest/test-unboxed-do... File test/cctest/test-unboxed-doubles.cc (right): https://codereview.chromium.org/2759433002/diff/1/test/cctest/test-unboxed-do... test/cctest/test-unboxed-doubles.cc:1414: obj_value = factory->NewJSArray(0, FAST_HOLEY_ELEMENTS); Requesting an empty array omits allocation of elements, therefore the CHECK below holds.
jkummerow@chromium.org changed reviewers: + ulan@chromium.org
Ulan added that test in https://codereview.chromium.org/1032833002. (These changes are probably fine, but I don't know why the "32KB" (which really means 32K elements) value was chosen originally. Is there maybe a reason to have a non-zero size?)
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== [regexp] Fix build failures triggered by RegExpStub port The arm64-nosnapshot failure looks like a broken test caused by changes in memory layout. It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. ppc and s390 just had compilation issues. BUG=v8:5339 ========== to ========== [cctest] Fix invalid assumption in test-unboxed-doubles test-unboxed-doubles/WriteBarrierObjectShiftFieldsRight recently started failing on arm64-nosnapshot builds (see [0]) due to a broken CHECK. It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. Fix it by ensuring only one allocation occurs. BUG=v8:5339 ==========
On 2017/03/16 16:07:37, Jakob Kummerow wrote: > Ulan added that test in https://codereview.chromium.org/1032833002. > > (These changes are probably fine, but I don't know why the "32KB" (which really > means 32K elements) value was chosen originally. Is there maybe a reason to have > a non-zero size?) I don't remember anymore why I put fixed array there :) I think we can use any object, including a heap number
Description was changed from ========== [cctest] Fix invalid assumption in test-unboxed-doubles test-unboxed-doubles/WriteBarrierObjectShiftFieldsRight recently started failing on arm64-nosnapshot builds (see [0]) due to a broken CHECK. It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. Fix it by ensuring only one allocation occurs. BUG=v8:5339 ========== to ========== [cctest] Fix invalid assumption in test-unboxed-doubles test-unboxed-doubles/WriteBarrierObjectShiftFieldsRight recently started failing on arm64-nosnapshot builds due to a broken CHECK. # Fatal error in ../../test/cctest/test-unboxed-doubles.cc, line 1417 # Check failed: heap->InNewSpace(*obj_value). It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. Fix it by ensuring only one allocation occurs. BUG=v8:5339 ==========
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
lgtm
The CQ bit was unchecked by jgruber@chromium.org
The CQ bit was checked by jgruber@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 40001, "attempt_start_ts": 1489744857897620, "parent_rev": "877d9758eb20cc92b5106bcb93ecb7a66c6d26d6", "commit_rev": "ad75ded221595bbdc1ec72d087fe8aa22bddb17b"}
Message was sent while issue was closed.
Description was changed from ========== [cctest] Fix invalid assumption in test-unboxed-doubles test-unboxed-doubles/WriteBarrierObjectShiftFieldsRight recently started failing on arm64-nosnapshot builds due to a broken CHECK. # Fatal error in ../../test/cctest/test-unboxed-doubles.cc, line 1417 # Check failed: heap->InNewSpace(*obj_value). It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. Fix it by ensuring only one allocation occurs. BUG=v8:5339 ========== to ========== [cctest] Fix invalid assumption in test-unboxed-doubles test-unboxed-doubles/WriteBarrierObjectShiftFieldsRight recently started failing on arm64-nosnapshot builds due to a broken CHECK. # Fatal error in ../../test/cctest/test-unboxed-doubles.cc, line 1417 # Check failed: heap->InNewSpace(*obj_value). It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. Fix it by ensuring only one allocation occurs. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2759433002 Cr-Commit-Position: refs/heads/master@{#43886} Committed: https://chromium.googlesource.com/v8/v8/+/ad75ded221595bbdc1ec72d087fe8aa22bd... ==========
Message was sent while issue was closed.
Committed patchset #3 (id:40001) as https://chromium.googlesource.com/v8/v8/+/ad75ded221595bbdc1ec72d087fe8aa22bd... |