-
-
Notifications
You must be signed in to change notification settings - Fork 31.5k
src: fix mismatched delete[] in src/node_file.cc #1092
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
No open issues about it yet. |
inline const char* dest() const { return dest_; } | ||
inline unsigned int dest_len() const { return dest_len_; } | ||
inline void dest_len(unsigned int dest_len) { dest_len_ = dest_len; } | ||
void* operator new(size_t size) = delete; |
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.
How does this work?
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.
Fix a bad delete of a pointer that was allocated with placement new. Casting the pointer was not the right solution because there was at least one non-placement new constructor call. This commit rewrites FSReqWrap to be more explicit about ownership of the auxiliary data and removes a number of egregious const_casts. The ASYNC_DEST_CALL macro also gets significantly slimmed down. PR-URL: nodejs#1092 Reviewed-By: Fedor Indutny <fedor@indutny.com>
The SYNC_CALL macro returns on error, bypassing the delete[] call. Mea culpa, it looks like I introduced this memory leak back in 2013, in commit d2b80b8 ("src: clean up FSReqWrap"). PR-URL: nodejs#1092 Reviewed-By: Fedor Indutny <fedor@indutny.com>
LGTM |
@indutny I pushed another commit to fix a memory leak in the fs.writeSync() error path. Can you PTAL? |
Those SYNC_CALL and ASYNC_CALL macros are a special kind of evil. One of the first rules of C macros is that you don't push control flow into them and what do they do? Exactly. |
return args.GetReturnValue().Set(SYNC_RESULT); | ||
} | ||
|
||
FSReqWrap* req_wrap = | ||
new FSReqWrap(env, req.As<Object>(), "write", must_free ? buf : nullptr); | ||
FSReqWrap::New(env, req.As<Object>(), "write", buf, ownership); |
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.
So you pas buf
here, where does it die?
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.
Anyway it seems that the buf
should be deallocated somewhere.
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.
It's freed by FSReqWrap's destructor because ownership == MOVE
.
One comment, otherwise LGTM |
FSReqWrap* that; | ||
char* const storage = new char[sizeof(*that) + size]; | ||
that = new(storage) FSReqWrap(env, req, syscall, data); | ||
if (copy) |
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.
Oh, I guess it becomes parts of FSReqWrap?
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.
Exactly. :-)
6f9e503
to
528d878
Compare
Fix a bad delete of a pointer that was allocated with placement new.
Casting the pointer was not the right solution because there was at
least one non-placement new constructor call.
This commit rewrites FSReqWrap to be more explicit about ownership of
the auxiliary data and removes a number of egregious const_casts.
The ASYNC_DEST_CALL macro also gets significantly slimmed down.
R=@indutny
Is there a bug number I should reference in the commit log?
https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/257/