Skip to content

Conversation

@Trott
Copy link
Member

693401d added stricter range checking
for buffer operations and that apparently seems to have uncovered the
fact that one of our benchmarks was overflowing a buffer. Increase the
buffer size so the benchmark doesn't throw an error anymore.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-botnodejs-github-bot added benchmark Issues and PRs related to the benchmark subsystem. buffer Issues and PRs related to the buffer subsystem. labels Apr 16, 2019
@TrottTrott requested a review from BridgeARApril 16, 2019 13:49
@TrottTrott changed the title buffer: fix buffer-base64--decode.jsbuffer: fix buffer-base64-decode.jsApr 16, 2019
@TrottTrottforce-pushed the fix-buffer-benchmark branch from 46d2dfc to 3db71caCompareApril 16, 2019 13:50
@Trott
Copy link
MemberAuthor

Trott commented Apr 16, 2019

Still need a fix for test-benchmark-buffes which sets values such that buffer-base64-encode also fails. Will get to that later if no one beats me to it (which would be great).

@mscdex
Copy link
Contributor

I think this should be using the benchmark: prefix instead of buffer: in the commit message?

@Trott
Copy link
MemberAuthor

Fixed the test too with a simple one-line change. A quick re-review would be great. @addaleax@jasnell

Trott added 2 commits April 16, 2019 08:29
693401d added stricter range checking for buffer operations and that apparently seems to have uncovered the fact that one of our benchmarks was overflowing a buffer. Increase the buffer size so the benchmark doesn't throw an error anymore.
Using `len=2` in test-benchmark-buffer was resulting in a `RangeError` in buffer-base64-encode.js. Change to `len=256` which works in all buffer benchmarks.
@TrottTrottforce-pushed the fix-buffer-benchmark branch from 2d01e7d to eab7d50CompareApril 16, 2019 15:29
@Trott
Copy link
MemberAuthor

I think this should be using the benchmark: prefix instead of buffer: in the commit message?

Fixed and force-pushed.

@TrottTrott changed the title buffer: fix buffer-base64-decode.jsbenchmark: fix buffer-base64-decode.jsApr 16, 2019
@BridgeAR
Copy link
Member

Still need a fix for test-benchmark-buffes which sets values such that buffer-base64-encode also fails.

Please add an assertion that the benchmark fails in case faulty len values are used. That way this would have been detected earlier as well.

@nodejs-github-bot
Copy link
Collaborator

@Trott
Copy link
MemberAuthor

Still need a fix for test-benchmark-buffes which sets values such that buffer-base64-encode also fails.

Please add an assertion that the benchmark fails in case faulty len values are used. That way this would have been detected earlier as well.

I'm not sure I understand. The benchmark test was failing. Adding an assertion for it wouldn't have detected it because it was already a failing test. (The problem is that the test is not run in CI except nightly, which is where i saw the failure.) The benchmark tests are intentionally minimal. I'm reluctant to test buffer functionality in them.

@BridgeAR
Copy link
Member

BridgeAR commented Apr 16, 2019

Adding an assertion for it wouldn't have detected it because it was already a failing test.

The test would have failed earlier that way and we have some very basic assertions in some benchmarks to validate the input parameters. Adding one here as well just seemed right to me but that's not a blocker (my other comment is).

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@TrottTrott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Apr 16, 2019
@Trott
Copy link
MemberAuthor

I'd like to fast-track this to unbreak the nightly CI that runs the benchmark tests. 👍 here to approve if you're a Collaborator, or leave a comment if you think it's just not that important and this should wait the remaining 24 hours. Thanks!

@TrottTrott added the fast-track PRs that do not need to wait for 48 hours to land. label Apr 17, 2019
@TrottTrott removed the fast-track PRs that do not need to wait for 48 hours to land. label Apr 18, 2019
@TrottTrott closed this Apr 18, 2019
Trott added a commit to Trott/io.js that referenced this pull request Apr 18, 2019
693401d added stricter range checking for buffer operations and that apparently seems to have uncovered the fact that one of our benchmarks was overflowing a buffer. Increase the buffer size so the benchmark doesn't throw an error anymore. PR-URL: nodejs#27260 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
Trott added a commit to Trott/io.js that referenced this pull request Apr 18, 2019
Using `len=2` in test-benchmark-buffer was resulting in a `RangeError` in buffer-base64-encode.js. Change to `len=256` which works in all buffer benchmarks. PR-URL: nodejs#27260 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
@Trott
Copy link
MemberAuthor

Landed in f98679f...d5bb500

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author readyPRs that have at least one approval, no pending requests for changes, and a CI started.benchmarkIssues and PRs related to the benchmark subsystem.bufferIssues and PRs related to the buffer subsystem.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@Trott@nodejs-github-bot@mscdex@BridgeAR@refack@jasnell@addaleax@lpinca