-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[deps] V8: cherry-pick 71736859756b2bd0444bdb0a87a #35205
Conversation
Is there a PR for 14 as well? |
Not yet, but I'll create one tomorrow. |
If this applies to the V8 version we have in master/v14.x, please only open a PR against master. It can then be backported to v12.x |
I can create a PR against master tomorrow 👍 |
729799d
to
c9bd1a7
Compare
982be1f
to
c012d6d
Compare
be41c83
to
efb5192
Compare
af49418
to
2cdb60d
Compare
efb5192
to
26f2d97
Compare
26f2d97
to
55fe022
Compare
55fe022
to
65b7bf4
Compare
@danbev Sorry to ask, but could you rebase this? |
No worries, I'll rebase shortly. |
Original commit message: [heap] Add large_object_threshold to AllocateRaw This commit adds a check in Heap::AllocateRaw when setting the large_object variable, when the AllocationType is of type kCode, to take into account the size of the CodeSpace's area size. The motivation for this change is that without this check it is possible that size_in_bytes is less than 128, and hence not considered a large object, but it might be larger than the available space in code_space->AreaSize(), which will cause the object to be created in the CodeLargeObjectSpace. This will later cause a segmentation fault when calling the following chain of functions: if (!large_object) { MemoryChunk::FromHeapObject(heap_object) ->GetCodeObjectRegistry() ->RegisterNewlyAllocatedCodeObject(heap_object.address()); } We (Red Hat) ran into this issue when running Node.js v12.16.1 in combination with yarn on aarch64 (this was the only architecture that this happed on). Bug: v8:10808 Change-Id: I0c396b0eb64bc4cc91d9a3be521254f3130eac7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390665 Commit-Queue: Ulan Degenbaev <[email protected]> Reviewed-by: Ulan Degenbaev <[email protected]> Cr-Commit-Position: refs/heads/master@{#69876} Refs: v8/v8@7173685
2cdb60d
to
11a0593
Compare
@danbev looks like the V8 CI fails for this PR. |
@richardlau Thanks again! And sorry about using CI instead of testing locally but I'm running low on disk space on my machine. |
Re-build of V8-CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/3395/ |
Landed in 57564eb |
Original commit message: [heap] Add large_object_threshold to AllocateRaw This commit adds a check in Heap::AllocateRaw when setting the large_object variable, when the AllocationType is of type kCode, to take into account the size of the CodeSpace's area size. The motivation for this change is that without this check it is possible that size_in_bytes is less than 128, and hence not considered a large object, but it might be larger than the available space in code_space->AreaSize(), which will cause the object to be created in the CodeLargeObjectSpace. This will later cause a segmentation fault when calling the following chain of functions: if (!large_object) { MemoryChunk::FromHeapObject(heap_object) ->GetCodeObjectRegistry() ->RegisterNewlyAllocatedCodeObject(heap_object.address()); } We (Red Hat) ran into this issue when running Node.js v12.16.1 in combination with yarn on aarch64 (this was the only architecture that this happed on). Bug: v8:10808 Change-Id: I0c396b0eb64bc4cc91d9a3be521254f3130eac7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390665 Commit-Queue: Ulan Degenbaev <[email protected]> Reviewed-by: Ulan Degenbaev <[email protected]> Cr-Commit-Position: refs/heads/master@{#69876} Refs: v8/v8@7173685 PR-URL: #35205 Reviewed-By: Anna Henningsen <[email protected]>
Was this backported to v14 as well? |
But that PR was closed without being merged? |
I can confirm that 14.15.4 does not contain the fix. |
Original commit message:
[heap] Add large_object_threshold to AllocateRaw
This commit adds a check in Heap::AllocateRaw when setting the
large_object variable, when the AllocationType is of type kCode, to
take into account the size of the CodeSpace's area size.
The motivation for this change is that without this check it is
possible that size_in_bytes is less than 128, and hence not considered
a large object, but it might be larger than the available space
in code_space->AreaSize(), which will cause the object to be created
in the CodeLargeObjectSpace. This will later cause a segmentation fault
when calling the following chain of functions:
We (Red Hat) ran into this issue when running Node.js v12.16.1 in
combination with yarn on aarch64 (this was the only architecture that
this happed on).
Bug: v8:10808
Change-Id: I0c396b0eb64bc4cc91d9a3be521254f3130eac7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390665
Commit-Queue: Ulan Degenbaev [email protected]
Reviewed-by: Ulan Degenbaev [email protected]
Cr-Commit-Position: refs/heads/master@{#69876}
Refs: v8/v8@7173685
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes