FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

src: use proper errors as coming from StringBytes by addaleax · Pull Request #14579 · nodejs/node · GitHub

/ node Public

src: use proper errors as coming from StringBytes - #14579

Closed
addaleax wants to merge 1 commit into
nodejs:masterfrom
addaleax:src-error-usage
Closed

src: use proper errors as coming from StringBytes#14579
addaleax wants to merge 1 commit into
nodejs:masterfrom
addaleax:src-error-usage

Conversation

addaleax commented Aug 1, 2017

Copy link
Copy Markdown
Member

The previous errors were incorrect here, as the code
only failed in situations where strings exceeded size limits or
an OOM situation was encountered, not for invalid encodings
(which aren’t even detected explicitly).

Unfortunately, these situations are hard to test for.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

src

addaleax added fs Issues and PRs related to the fs subsystem / file system. lib / src Issues and PRs related to general changes in the lib or src directory. os Issues and PRs related to the os subsystem. semver-major PRs that contain breaking changes and should be released in the next major version. labels Aug 1, 2017
nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. fs Issues and PRs related to the fs subsystem / file system. os Issues and PRs related to the os subsystem. labels Aug 1, 2017
Comment thread src/node_file.cc Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

return env->isolate()->ThrowException(error);? The call to rc.ToLocalChecked() two lines down will fail if you fall through.

Same issue appears a few more times further down in this file.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

done

Comment thread src/node_os.cc Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Stylistic change.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

fixed up, this was not intentional

Comment thread src/node_os.cc Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Suggestion: move the .IsEmpty() checks to after the StringBytes::Encode() calls, then you don't have to do the goto jump-around thing.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

error is cleared by StringBytes::Encode() if the call succeeded… I’ve thought about doing that, would you prefer to change that behaviour? I can see the advantage that would have.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Good idea. I was thinking of guarding the Encode() calls with an error.IsEmpty() check but that's a good idea.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

@bnoordhuis Done, PTAL!

addaleax force-pushed the src-error-usage branch 3 times, most recently from 4951e75 to 84a16b0 Compare August 7, 2017 12:48

Copy link
Copy Markdown
Member Author

@bnoordhuis Mind taking another look?

Comment thread src/node_os.cc Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Mildly unrelated change.

The previous errors were incorrect here, as the code
only failed in situations where strings exceeded size limits or
an OOM situation was encountered, not for invalid encodings
(which aren’t even detected explicitly).

Unfortunately, these situations are hard to test for.

PR-URL: nodejs#14579
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

Copy link
Copy Markdown
Member Author

CI: https://ci.nodejs.org/job/node-test-commit/11985/

This should be ready.

jasnell commented Aug 23, 2017

Copy link
Copy Markdown
Member

@addaleax ... fyi https://ci.nodejs.org/job/node-test-commit-aix/8108/nodes=aix61-ppc64/console

Can you check to see if this failure is related to the change?

Copy link
Copy Markdown
Member Author

Ugh … a lot of the Linux failures are the same, so, probably? test-commit-linux on master for comparison: https://ci.nodejs.org/job/node-test-commit-linux/12023/

Copy link
Copy Markdown
Member Author

Sigh. Yes, also a problem on master, so I’ll take a look.

jasnell commented Aug 24, 2017
edited
Loading

Copy link
Copy Markdown
Member

I'm digging in also. :-) This wasn't a problem earlier today so it has to be one of the PRs landed today.... and I can't get to Jenkins... sigh. Will keep trying

Copy link
Copy Markdown
Member Author

@jasnell I think it’s only 32-bit systems (?) My guess would be

node/src/node_perf.cc

Lines 318 to 327 in c6da5c8

#define SET_STATE_TYPEDARRAY(name, type, field) \
target->Set(context, \
FIXED_ONE_BYTE_STRING(isolate, (name)), \
type::New(state_ab, \
offsetof(performance_state, field), \
arraysize(state->field))) \
.FromJust()
SET_STATE_TYPEDARRAY("observerCounts", v8::Uint32Array, observers);
SET_STATE_TYPEDARRAY("milestones", v8::Float64Array, milestones);
#undef SET_STATE_TYPEDARRAY

I realize that’s kind of my code because it mirrors the HTTP2 one, so … uuh. 😄

Copy link
Copy Markdown
Member Author

Heh, okay, I think I got this.

jasnell commented Aug 24, 2017

Copy link
Copy Markdown
Member

Um.. that's confusing then :-/ ... the CI was good for that PR even on 32 bit system.

What do you have?

Copy link
Copy Markdown
Member Author

Landed in 784c6d4

(for the record, the above conversation was finished in #14996)

addaleax closed this Aug 24, 2017
addaleax deleted the src-error-usage branch August 24, 2017 19:09
addaleax added a commit that referenced this pull request Aug 24, 2017
The previous errors were incorrect here, as the code
only failed in situations where strings exceeded size limits or
an OOM situation was encountered, not for invalid encodings
(which aren’t even detected explicitly).

Unfortunately, these situations are hard to test for.

PR-URL: #14579
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
addaleax added a commit to addaleax/ayo that referenced this pull request Aug 25, 2017
The previous errors were incorrect here, as the code
only failed in situations where strings exceeded size limits or
an OOM situation was encountered, not for invalid encodings
(which aren’t even detected explicitly).

Unfortunately, these situations are hard to test for.

PR-URL: nodejs/node#14579
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
addaleax added a commit to ayojs/ayo that referenced this pull request Aug 28, 2017
The previous errors were incorrect here, as the code
only failed in situations where strings exceeded size limits or
an OOM situation was encountered, not for invalid encodings
(which aren’t even detected explicitly).

Unfortunately, these situations are hard to test for.

PR-URL: nodejs/node#14579
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

c++ Issues and PRs that require attention from people who are familiar with C++. fs Issues and PRs related to the fs subsystem / file system. lib / src Issues and PRs related to general changes in the lib or src directory. os Issues and PRs related to the os subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants


Back | FazBrowse Home | New Git URL