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

Do not reset globals when set as returnvalues #493

Closed
wants to merge 1 commit into from

Conversation

kkoopa
Copy link
Collaborator

@kkoopa kkoopa commented Oct 12, 2015

No description provided.

@brodybits
Copy link

Is there a test scenario that can reproduce the bug and verify that it is fixed? I am happy to contribute the test scenario if you like.

@kkoopa
Copy link
Collaborator Author

kkoopa commented Oct 20, 2015

I don't think there is one, but I don't know how to test this either. The thing is that Globals are supposed to be reset automatically when they go out of scope and their destructors are called.
So, in this code

NAN_METHOD(foo) {
    info.GetReturnValue().Set(Nan::Global<v8::Value>(Nan::New(4)));
}

The Global should be automatically reset as soon as the return value has been set, thereby not leaking. However, the stored return value should not be destroyed by this and remain available until its time has come. Moreover, Globals should support move semantics, so what should really happen is that the underlying storage cell is assigned to the return value container, the Global is cleared so that its storage cell is now only referenced by the return value, then that storage cell should finally be reset when the return value is destroyed.

So it would need to test that there are no memory leaks and no use-after-frees. Also, 78fa1c4 should be included.

@brodybits
Copy link

78fa1c4 should be included.

78fa1c4 part of #492 (it took me a few minutes to find it by following the link then changing nodejs to kkoopa in the link).

@brodybits
Copy link

To be honest Global is still very new to me. It does make sense to me that this is not so easy to test. I am thinking valgrind is the best way to check for the memory problems such as leaks, double-free(s), and use after free. In addition, we should make sure the code is covered (ideally using automatic code coverage tools).

Hoping to see your fixes land soon.

@kkoopa
Copy link
Collaborator Author

kkoopa commented Oct 20, 2015

Yeah, holding off on this right now due to the risks of introducing new problems. Will do some manual testing at some point to get these properly integrated.

@kkoopa kkoopa added this to the 3.0 milestone Jan 9, 2016
@kkoopa kkoopa modified the milestones: 2.4, 3.0 Jun 13, 2016
@kkoopa
Copy link
Collaborator Author

kkoopa commented Jun 13, 2016

This should go in 2.4

@kkoopa kkoopa closed this Jun 14, 2016
@kkoopa kkoopa deleted the global_bugfix branch June 14, 2016 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants