| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Maybe add a regression test? |
Sorry, something went wrong.
|
Tested locally and can confirm this fixes master + v5 |
Sorry, something went wrong.
|
Regression test for sure. Otherwise LGTM. |
Sorry, something went wrong.
|
LGTM pending a test. |
Sorry, something went wrong.
|
Added some tests |
Sorry, something went wrong.
There was a problem hiding this comment.
style: missing newline
Sorry, something went wrong.
There was a problem hiding this comment.
fixed!
Sorry, something went wrong.
|
LGTM if CI is happy |
Sorry, something went wrong.
Sorry, something went wrong.
|
LGTM |
Sorry, something went wrong.
There was a problem hiding this comment.
ha! sigh... I had uint8 on the brain I guess. good catch.
Sorry, something went wrong.
There was a problem hiding this comment.
Also -0 could be a factor, but I'm not sure. Any way, tests are a bit non-deterministic, since even if there is no actual zero filling, there is still a chance that some allocations would be zeros
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, that came up in the original review. It's not a great test. The plan was to revisit to see if the test can be made more robust.
Sorry, something went wrong.
There was a problem hiding this comment.
Also for some reason this bug is hard to reproduce with small Uint8Array.
Sorry, something went wrong.
There was a problem hiding this comment.
Looking at it now this one should have been obvious :-/. The bug only shows up after doing a pooled unsafeAlloc allocation because the zero fill flag was never being reset (because a real allocation wasn't being done).
(update: ha! I see you noted that in your commit log... it's definitely a friday)
Sorry, something went wrong.
If `kNoZeroFill` is set here, it won't be reset in case of pooled allocation. In case of "slow" allocation it will be set later anyway. Fixes: nodejs#6006
|
CI looks good. One unrelated failure. |
Sorry, something went wrong.
If `kNoZeroFill` is set here, it won't be reset in case of pooled allocation. In case of "slow" allocation it will be set later anyway. Fixes: #6006 PR-URL: #6007 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
|
Will cherry-pick this into v5.x as well. |
Sorry, something went wrong.
If `kNoZeroFill` is set here, it won't be reset in case of pooled allocation. In case of "slow" allocation it will be set later anyway. Fixes: #6006 PR-URL: #6007 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
|
CVE? |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Pull Request check-list
this change (including linting)?
test (or a benchmark) included?
existing APIs, or introduces new ones)?
Affected core subsystem(s)
buffer
Description of change
If kNoZeroFill is set here, it won't be reset in case of
pooled allocation. In case of "slow" allocation it will be
set later anyway.
Fixes: #6006