Skip to content
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

src: fix check for accepting Buffers into Node’s allocator #27174

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
7 participants
@addaleax
Copy link
Member

commented Apr 10, 2019

This condition was incorrect. We currently take the fallback
path in default Node builds, which always works, but may come with
some overhead, whereas the intention was that we use the fast path
in this condition.

This is causing issues for embedders, because we would erroneously
try to take the fast path when they don’t provide a Node.js-style
ArrayBufferAlloactor, and crash as a consequence of that.

This also requires us to relax the check in the debugging ArrayBuffer
allocator a bit, because since d117e41, 0-sized ArrayBuffers
may actually point to allocations of size 1. Previously, that wasn’t
caught because the fallback path circumvented our ArrayBufferAllocator.

Refs: 84e02b1#r33116006

/cc @zcbenz

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
src: fix check for accepting Buffers into Node’s allocator
This condition was incorrect. We currently take the fallback
path in default Node builds, which always works, but may come with
some overhead, whereas the intention was that we use the fast path
in this condition.

This is causing issues for embedders, because we would erroneously
try to take the fast path when they don’t provide a Node.js-style
`ArrayBufferAlloactor`, and crash as a consequence of that.

This also requires us to relax the check in the debugging ArrayBuffer
allocator a bit, because since d117e41, 0-sized ArrayBuffers
may actually point to allocations of size 1. Previously, that wasn’t
caught because the fallback path circumvented our ArrayBufferAllocator.

Refs: 84e02b1#r33116006
@nodejs-github-bot

This comment has been minimized.

addaleax referenced this pull request Apr 10, 2019

src: allocate Buffer memory using ArrayBuffer allocator
Always use the right allocator for memory that is turned into
an `ArrayBuffer` at a later point.

This enables embedders to use their own `ArrayBuffer::Allocator`s,
and is inspired by Electron’s electron/node@f61bae3. It should
render their downstream patch unnecessary.

Refs: electron/node@f61bae3

PR-URL: #26207
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@joyeecheung

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

BTW, is it possible to cctest this now?

@addaleax

This comment has been minimized.

Copy link
Member Author

commented Apr 10, 2019

It would be, but our cctest helpers aren’t really written to accommodate this…

@@ -138,7 +138,11 @@ void DebuggingArrayBufferAllocator::UnregisterPointerInternal(void* data,
if (data == nullptr) return;
auto it = allocations_.find(data);
CHECK_NE(it, allocations_.end());
CHECK_EQ(it->second, size);
if (size > 0) {

This comment has been minimized.

Copy link
@cjihrig

cjihrig Apr 10, 2019

Contributor

Would this be a good place to use CHECK_IMPLIES()?

This comment has been minimized.

Copy link
@addaleax

addaleax Apr 14, 2019

Author Member

@cjihrig Does it make a difference? If I want to say “this check is only valid under these conditions”, then I am okay with using an if

This comment has been minimized.

Copy link
@cjihrig

cjihrig Apr 14, 2019

Contributor

It shouldn't make a difference. I just thought it might be a bit more concise and possibly (I'm not sure) simplify code coverage.

This comment has been minimized.

Copy link
@addaleax

addaleax Apr 14, 2019

Author Member

Yeah, I’d prefer to keep this as it is here. I’ve noticed this because of failing tests, so I think code coverage isn’t an issue either.

@nodejs-github-bot

This comment has been minimized.

@addaleax

This comment has been minimized.

Copy link
Member Author

commented Apr 14, 2019

Landed in 427fce7

@addaleax addaleax closed this Apr 14, 2019

@addaleax addaleax deleted the addaleax:buffer-new-fast-path branch Apr 14, 2019

addaleax added a commit that referenced this pull request Apr 14, 2019

src: fix check for accepting Buffers into Node’s allocator
This condition was incorrect. We currently take the fallback
path in default Node builds, which always works, but may come with
some overhead, whereas the intention was that we use the fast path
in this condition.

This is causing issues for embedders, because we would erroneously
try to take the fast path when they don’t provide a Node.js-style
`ArrayBufferAlloactor`, and crash as a consequence of that.

This also requires us to relax the check in the debugging ArrayBuffer
allocator a bit, because since d117e41, 0-sized ArrayBuffers
may actually point to allocations of size 1. Previously, that wasn’t
caught because the fallback path circumvented our ArrayBufferAllocator.

Refs: 84e02b1#r33116006

PR-URL: #27174
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.