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

inspector: Simplify buffer management #8257

Closed
wants to merge 1 commit into from
Closed

inspector: Simplify buffer management #8257

wants to merge 1 commit into from

Conversation

eugeneo
Copy link
Contributor

@eugeneo eugeneo commented Aug 24, 2016

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

This only touches the protocol implementation for the V8 inspector.

Description of change

This change simplifies buffer management to address a number of issues
that original implementation had.

Original implementation was trying to reduce the number of allocations
by providing regions of the internal buffer to libuv IO code. This
introduced some potential use after free issues if the buffer grows
(or shrinks) while there's a pending read. It also had some confusing
math that resulted in issues on Windows version of the libuv.

Fixes: #8155
CC: @ofrobots

@mscdex mscdex added buffer Issues and PRs related to the buffer subsystem. inspector Issues and PRs related to the V8 inspector protocol c++ Issues and PRs that require attention from people who are familiar with C++. labels Aug 24, 2016
@joaocgreis
Copy link
Member

I confirm this fixes #8155 for me under Windows 2012.

@@ -48,16 +49,17 @@ static void dump_hex(const char* buf, size_t len) {
}
#endif

static void remove_from_beginning(std::vector<char>* buffer, size_t count) {
Copy link
Member

Choose a reason for hiding this comment

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

nit: I’m fine with having this the way it is, but to me using pointers to STL containers always seems a bit unidiomatic – this seems like a very okay place to use references?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used a pointer here to indicate that the parameter will be modified... Should I use a non-const ref?

Copy link
Member

Choose a reason for hiding this comment

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

I don’t feel too strongly about it. I’d personally have opted for a non-const reference, but if you or anyone else prefers it this way, that’s definitely okay too.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think @eugeneo is following this rationale which I subscribe to as well (I might be biased though :).

Copy link
Member

Choose a reason for hiding this comment

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

The house style in node.js is pointers when arguments are modified. References should always be const.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for clarifying, both of you :)

@addaleax
Copy link
Member

return FRAME_INCOMPLETE;

const char* p = buffer_begin;
const char* buffer_end = p + data_length;
std::vector<char>::const_iterator p = buffer.begin();
Copy link
Member

@bnoordhuis bnoordhuis Aug 26, 2016

Choose a reason for hiding this comment

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

I'd be okay with writing this as auto p = buffer.cbegin() (but maybe call it it to make it clear it's an iterator, not a pointer.)

EDIT: Or auto p = buffer.begin(), seeing that buffer is already const.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@eugeneo
Copy link
Contributor Author

eugeneo commented Aug 26, 2016

I addressed the comments and uploaded a new version. Thank you for the review. Please take another look.

inspector_socket_t* inspector_from_stream(void* client) {
return node::ContainerOf(&inspector_socket_t::client,
reinterpret_cast<uv_tcp_t*>(client));
}
Copy link
Member

Choose a reason for hiding this comment

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

This could be made a little more type-safe by having overloads for uv_handle_t and uv_stream_t:

inspector_socket_t* inspector_from_tcp(uv_tcp_t* client) {
  return node::ContainerOf(&inspector_socket_t::client, client);
}
inspector_socket_t* inspector_from_stream(uv_stream_t* client) {
  return inspector_from_tcp(reinterpret_cast<uv_tcp_t*>(client));
}
inspector_socket_t* inspector_from_handle(uv_handle_t* client) {
  return inspector_from_tcp(reinterpret_cast<uv_tcp_t*>(client));
}

@bnoordhuis
Copy link
Member

LGTM with a suggestion.

This change simplifies buffer management to address a number of issues
that original implementation had.

Original implementation was trying to reduce the number of allocations
by providing regions of the internal buffer to libuv IO code. This
introduced some potential use after free issues if the buffer grows
(or shrinks) while there's a pending read. It also had some confusing
math that resulted in issues on Windows version of the libuv.

Fixes: #8155
@eugeneo
Copy link
Contributor Author

eugeneo commented Aug 29, 2016

Thank you for the review. I've implemented the suggestion. Please take another look.

@bnoordhuis
Copy link
Member

LGTM but s/Simplify/simplify/ in the commit log status line (it's normally all lower case.)

@bnoordhuis
Copy link
Member

LGTM

@ofrobots
Copy link
Contributor

@jasnell
Copy link
Member

jasnell commented Aug 30, 2016

CI is red, looks like a build bot failure.

@ofrobots
Copy link
Contributor

ARM fanned builds seemed to be having issues yesterday. Let's hit the CI one more time: https://ci.nodejs.org/job/node-test-pull-request/3904/

@ofrobots
Copy link
Contributor

New CI has a failure on the new ubuntu1204-clang-3.4.1 bot (expected, see #8343). The timeout on the mac build looks like a flake. I will land this shortly.

ofrobots pushed a commit that referenced this pull request Aug 31, 2016
This change simplifies buffer management to address a number of issues
that original implementation had.

Original implementation was trying to reduce the number of allocations
by providing regions of the internal buffer to libuv IO code. This
introduced some potential use after free issues if the buffer grows
(or shrinks) while there's a pending read. It also had some confusing
math that resulted in issues on Windows version of the libuv.

PR-URL: #8257
Fixes: #8155
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
@ofrobots
Copy link
Contributor

Landed as b6db963.

@ofrobots ofrobots closed this Aug 31, 2016
@Fishrock123 Fishrock123 mentioned this pull request Sep 6, 2016
Fishrock123 pushed a commit to Fishrock123/node that referenced this pull request Sep 8, 2016
This change simplifies buffer management to address a number of issues
that original implementation had.

Original implementation was trying to reduce the number of allocations
by providing regions of the internal buffer to libuv IO code. This
introduced some potential use after free issues if the buffer grows
(or shrinks) while there's a pending read. It also had some confusing
math that resulted in issues on Windows version of the libuv.

PR-URL: nodejs#8257
Fixes: nodejs#8155
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Fishrock123 pushed a commit that referenced this pull request Sep 9, 2016
This change simplifies buffer management to address a number of issues
that original implementation had.

Original implementation was trying to reduce the number of allocations
by providing regions of the internal buffer to libuv IO code. This
introduced some potential use after free issues if the buffer grows
(or shrinks) while there's a pending read. It also had some confusing
math that resulted in issues on Windows version of the libuv.

PR-URL: #8257
Fixes: #8155
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
@eugeneo eugeneo deleted the buffer branch September 16, 2016 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
buffer Issues and PRs related to the buffer subsystem. c++ Issues and PRs that require attention from people who are familiar with C++. inspector Issues and PRs related to the V8 inspector protocol
Projects
None yet
Development

Successfully merging this pull request may close these issues.

assertion when attaching the Chrome dev tools
8 participants