-
Notifications
You must be signed in to change notification settings - Fork 30k
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
Conversation
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) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
return FRAME_INCOMPLETE; | ||
|
||
const char* p = buffer_begin; | ||
const char* buffer_end = p + data_length; | ||
std::vector<char>::const_iterator p = buffer.begin(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
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)); | ||
} |
There was a problem hiding this comment.
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));
}
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
Thank you for the review. I've implemented the suggestion. Please take another look. |
LGTM but s/Simplify/simplify/ in the commit log status line (it's normally all lower case.) |
LGTM |
CI is red, looks like a build bot failure. |
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/ |
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. |
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>
Landed as b6db963. |
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>
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>
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected 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