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

buffer: convert offset & length to int properly #9815

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
9 participants
@thefourtheye
Contributor

thefourtheye commented Nov 27, 2016

Checklist
  • make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

buffer util

Description of change

As per ecma-262 2015's #sec-%typedarray%-buffer-byteoffset-length,
offset would be an integer, not a 32 bit unsigned integer. Also,
length would be an integer with the maximum value of 2^53 - 1, not a
32 bit unsigned integer.

This would be a problem because, if we create a buffer from an
arraybuffer, from an offset which is greater than 2^32, it would be
actually pointing to a different location in arraybuffer. For example,
if we use 2^40 as offset, then the actual value used will be 0,
because byteOffset >>>= 0 will convert byteOffset to a 32 bit
unsigned int, which is based on 2^32 modulo.

This is a redo, as the ca37fa5 broke
CI.

Refer: #9814
Refer: #9492


cc @nodejs/buffer @Trott

CI Run: https://ci.nodejs.org/job/node-test-pull-request/4990/

buffer: convert offset & length to int properly
As per ecma-262 2015's #sec-%typedarray%-buffer-byteoffset-length,
`offset` would be an integer, not a 32 bit unsigned integer. Also,
`length` would be an integer with the maximum value of 2^53 - 1, not a
32 bit unsigned integer.

This would be a problem because, if we create a buffer from an
arraybuffer, from an offset which is greater than 2^32, it would be
actually pointing to a different location in arraybuffer. For example,
if we use 2^40 as offset, then the actual value used will be 0,
because `byteOffset >>>= 0` will convert `byteOffset` to a 32 bit
unsigned int, which is based on 2^32 modulo.

This is a redo, as the ca37fa5 broke
CI.

Refer: #9814
Refer: #9492
@thefourtheye

This comment has been minimized.

Show comment
Hide comment
Contributor

thefourtheye commented Nov 27, 2016

@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye
Contributor

thefourtheye commented Nov 27, 2016

@targos

targos approved these changes Nov 27, 2016

LGTM

@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye

thefourtheye Dec 2, 2016

Contributor

@nodejs/collaborators Landing this tomorrow, if there are no objections.

Contributor

thefourtheye commented Dec 2, 2016

@nodejs/collaborators Landing this tomorrow, if there are no objections.

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina Dec 2, 2016

Member

LGTM

Member

mcollina commented Dec 2, 2016

LGTM

@jasnell

jasnell approved these changes Dec 2, 2016

@cjihrig

cjihrig approved these changes Dec 2, 2016

@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye
Contributor

thefourtheye commented Dec 3, 2016

@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye

thefourtheye Dec 5, 2016

Contributor

Landed in 720d01f

Contributor

thefourtheye commented Dec 5, 2016

Landed in 720d01f

@thefourtheye thefourtheye deleted the thefourtheye:redo-9492 branch Dec 5, 2016

thefourtheye added a commit that referenced this pull request Dec 5, 2016

buffer: convert offset & length to int properly
As per ecma-262 2015's #sec-%typedarray%-buffer-byteoffset-length,
`offset` would be an integer, not a 32 bit unsigned integer. Also,
`length` would be an integer with the maximum value of 2^53 - 1, not a
32 bit unsigned integer.

This would be a problem because, if we create a buffer from an
arraybuffer, from an offset which is greater than 2^32, it would be
actually pointing to a different location in arraybuffer. For example,
if we use 2^40 as offset, then the actual value used will be 0,
because `byteOffset >>>= 0` will convert `byteOffset` to a 32 bit
unsigned int, which is based on 2^32 modulo.

This is a redo, as the ca37fa5 broke
CI.

Refer: #9814
Refer: #9492

PR-URL: #9815

Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Fishrock123 added a commit that referenced this pull request Dec 5, 2016

buffer: convert offset & length to int properly
As per ecma-262 2015's #sec-%typedarray%-buffer-byteoffset-length,
`offset` would be an integer, not a 32 bit unsigned integer. Also,
`length` would be an integer with the maximum value of 2^53 - 1, not a
32 bit unsigned integer.

This would be a problem because, if we create a buffer from an
arraybuffer, from an offset which is greater than 2^32, it would be
actually pointing to a different location in arraybuffer. For example,
if we use 2^40 as offset, then the actual value used will be 0,
because `byteOffset >>>= 0` will convert `byteOffset` to a 32 bit
unsigned int, which is based on 2^32 modulo.

This is a redo, as the ca37fa5 broke
CI.

Refer: #9814
Refer: #9492

PR-URL: #9815

Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

@Fishrock123 Fishrock123 referenced this pull request Dec 5, 2016

Merged

v7.2.1 proposal #10127

2 of 2 tasks complete
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 7, 2016

Member

I hate to say it, but it sure looks like the test is broken on SmartOS. See, for example, https://ci.nodejs.org/job/node-test-commit-smartos/5632/nodes=smartos15-64/console:

not ok 109 parallel/test-buffer-creation-regression
  ---
  duration_ms: 76.135
  severity: fail
  stack: |-
    timeout
Member

Trott commented Dec 7, 2016

I hate to say it, but it sure looks like the test is broken on SmartOS. See, for example, https://ci.nodejs.org/job/node-test-commit-smartos/5632/nodes=smartos15-64/console:

not ok 109 parallel/test-buffer-creation-regression
  ---
  duration_ms: 76.135
  severity: fail
  stack: |-
    timeout
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 7, 2016

Member

(Since it may be just that the test is taking too long to finish, the solution may be to move the test to sequential and/or split each of the three test cases into its own test file so each test case has the full 60 seconds to run.)

Member

Trott commented Dec 7, 2016

(Since it may be just that the test is taking too long to finish, the solution may be to move the test to sequential and/or split each of the three test cases into its own test file so each test case has the full 60 seconds to run.)

@Trott Trott referenced this pull request Dec 7, 2016

Closed

test: move long-running test to sequential #10161

2 of 2 tasks complete
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 7, 2016

Member

Moved to sequential in #10161. If that's insufficient, I'll try breaking it into multiple tests.

Member

Trott commented Dec 7, 2016

Moved to sequential in #10161. If that's insufficient, I'll try breaking it into multiple tests.

jmdarling added a commit to jmdarling/node that referenced this pull request Dec 8, 2016

buffer: convert offset & length to int properly
As per ecma-262 2015's #sec-%typedarray%-buffer-byteoffset-length,
`offset` would be an integer, not a 32 bit unsigned integer. Also,
`length` would be an integer with the maximum value of 2^53 - 1, not a
32 bit unsigned integer.

This would be a problem because, if we create a buffer from an
arraybuffer, from an offset which is greater than 2^32, it would be
actually pointing to a different location in arraybuffer. For example,
if we use 2^40 as offset, then the actual value used will be 0,
because `byteOffset >>>= 0` will convert `byteOffset` to a 32 bit
unsigned int, which is based on 2^32 modulo.

This is a redo, as the ca37fa5 broke
CI.

Refer: nodejs#9814
Refer: nodejs#9492

PR-URL: nodejs#9815

Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Dec 20, 2016

Member

@thefourtheye should this be backported? I figure we should likely wait a bit to make sure there are not other breakages

Member

MylesBorins commented Dec 20, 2016

@thefourtheye should this be backported? I figure we should likely wait a bit to make sure there are not other breakages

@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye

thefourtheye Dec 20, 2016

Contributor

@thealphanerd This is actually a bug fix and we can backport this. We just have to backport all the relevant commits in the same order so that CI will not fail. I can backport this, if you are okay.

Contributor

thefourtheye commented Dec 20, 2016

@thealphanerd This is actually a bug fix and we can backport this. We just have to backport all the relevant commits in the same order so that CI will not fail. I can backport this, if you are okay.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins
Member

MylesBorins commented Dec 21, 2016

@thefourtheye please do

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Jan 11, 2017

Contributor

@MylesBorins should this be reopened while the commits are backported?

Contributor

trevnorris commented Jan 11, 2017

@MylesBorins should this be reopened while the commits are backported?

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Jan 11, 2017

Contributor

oh, guess we can't since the branch was deleted.

Contributor

trevnorris commented Jan 11, 2017

oh, guess we can't since the branch was deleted.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins
Member

MylesBorins commented Jan 23, 2017

@thefourtheye thefourtheye referenced this pull request Feb 5, 2017

Closed

Backport 9815 & 10161 to v6.x #11176

3 of 3 tasks complete
@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye

thefourtheye Feb 5, 2017

Contributor

@MylesBorins I backported this in #11176

Contributor

thefourtheye commented Feb 5, 2017

@MylesBorins I backported this in #11176

@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye

thefourtheye Feb 5, 2017

Contributor

Removed 4.x lts watch, as this patch is not applicable to 4.x branch. It doesn't have the fromArrayBuffer function itself.

Contributor

thefourtheye commented Feb 5, 2017

Removed 4.x lts watch, as this patch is not applicable to 4.x branch. It doesn't have the fromArrayBuffer function itself.

jasnell added a commit that referenced this pull request Mar 3, 2017

buffer: convert offset & length to int properly
  As per ecma-262 2015's #sec-%typedarray%-buffer-byteoffset-length,
  `offset` would be an integer, not a 32 bit unsigned integer. Also,
  `length` would be an integer with the maximum value of 2^53 - 1, not a
  32 bit unsigned integer.

  This would be a problem because, if we create a buffer from an
  arraybuffer, from an offset which is greater than 2^32, it would be
  actually pointing to a different location in arraybuffer. For example,
  if we use 2^40 as offset, then the actual value used will be 0,
  because `byteOffset >>>= 0` will convert `byteOffset` to a 32 bit
  unsigned int, which is based on 2^32 modulo.

  This is a redo, as the ca37fa5 broke
  CI.

  Refer: #9814
  Refer: #9492

  PR-URL: #9815

  Reviewed-By: Michaël Zasso <targos@protonmail.com>
  Reviewed-By: Trevor Norris <trev.norris@gmail.com>
  Reviewed-By: James M Snell <jasnell@gmail.com>
  Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
  Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Backport-Of: #9815
PR-URL: #11176
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Mar 9, 2017

buffer: convert offset & length to int properly
  As per ecma-262 2015's #sec-%typedarray%-buffer-byteoffset-length,
  `offset` would be an integer, not a 32 bit unsigned integer. Also,
  `length` would be an integer with the maximum value of 2^53 - 1, not a
  32 bit unsigned integer.

  This would be a problem because, if we create a buffer from an
  arraybuffer, from an offset which is greater than 2^32, it would be
  actually pointing to a different location in arraybuffer. For example,
  if we use 2^40 as offset, then the actual value used will be 0,
  because `byteOffset >>>= 0` will convert `byteOffset` to a 32 bit
  unsigned int, which is based on 2^32 modulo.

  This is a redo, as the ca37fa5 broke
  CI.

  Refer: #9814
  Refer: #9492

  PR-URL: #9815

  Reviewed-By: Michaël Zasso <targos@protonmail.com>
  Reviewed-By: Trevor Norris <trev.norris@gmail.com>
  Reviewed-By: James M Snell <jasnell@gmail.com>
  Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
  Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Backport-Of: #9815
PR-URL: #11176
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment