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

src: make AtExit callback's per Environment #9163

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
7 participants
@danbev
Member

danbev commented Oct 18, 2016

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

src

Description of change

This commit attempts to address one of the TODOs in
#4641 regarding making the AtExit
callback's per environment, instead of the current global.

bnoordhuis provided a few options for solving this and one was to use
a thread-local which is what this commit attempts to do..

@danbev

This comment has been minimized.

Show comment
Hide comment

@danbev danbev referenced this pull request Oct 18, 2016

Closed

src: make Environment optional for RunAtExit #9097

2 of 2 tasks complete
Show outdated Hide outdated src/node.cc
}
thread_local Environment* thread_local_env;

This comment has been minimized.

@addaleax

addaleax Oct 18, 2016

Member
  • Should this be static?
  • I think this doesn’t need an explicit initializer, but would you mind adding = nullptr just for clarity?
@addaleax

addaleax Oct 18, 2016

Member
  • Should this be static?
  • I think this doesn’t need an explicit initializer, but would you mind adding = nullptr just for clarity?

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

I'd leave out the = nullptr, it looks unidiomatic. It should be static though, yes.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

I'd leave out the = nullptr, it looks unidiomatic. It should be static though, yes.

This comment has been minimized.

@danbev

danbev Oct 19, 2016

Member

@addaleax @bnoordhuis I'd like to make sure I understand the reason for making this static. My understanding is that a thread_local object is allocated when the thread begins and deallocated when the thread ends, so static in this case does not refer to storage but to linkage. And without the explicitstatic, the linkage would be external by default. Does that sound correct?

@danbev

danbev Oct 19, 2016

Member

@addaleax @bnoordhuis I'd like to make sure I understand the reason for making this static. My understanding is that a thread_local object is allocated when the thread begins and deallocated when the thread ends, so static in this case does not refer to storage but to linkage. And without the explicitstatic, the linkage would be external by default. Does that sound correct?

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 19, 2016

Member

Correct. static in this context is about linkage, not lifetime. Without static, the variable is visible to other compilation units.

@bnoordhuis

bnoordhuis Oct 19, 2016

Member

Correct. static in this context is about linkage, not lifetime. Without static, the variable is visible to other compilation units.

This comment has been minimized.

@danbev

danbev Oct 19, 2016

Member

@bnoordhuis Thanks for clarifying that, I appreciate it.

@danbev

danbev Oct 19, 2016

Member

@bnoordhuis Thanks for clarifying that, I appreciate it.

Show outdated Hide outdated src/env.h
AtExitCallback* next_;
void (*cb_)(void* arg);
void* arg_;
};

This comment has been minimized.

@addaleax

addaleax Oct 18, 2016

Member

Just a suggestion, but you could make AtExitCallback a forward declaration in the node namespace here and only define it right before AtExit/RunAtExit. That would make sense insofar as the exact layout isn’t part of the API here, and having the definition of the struct close to its actual usage might be a tad more readable.

@addaleax

addaleax Oct 18, 2016

Member

Just a suggestion, but you could make AtExitCallback a forward declaration in the node namespace here and only define it right before AtExit/RunAtExit. That would make sense insofar as the exact layout isn’t part of the API here, and having the definition of the struct close to its actual usage might be a tad more readable.

This comment has been minimized.

@danbev

danbev Oct 19, 2016

Member

That sounds good, I'll change that.

@danbev

danbev Oct 19, 2016

Member

That sounds good, I'll change that.

Show outdated Hide outdated src/node.cc
delete p;
p = q;
}
env->RunAtExit();

This comment has been minimized.

@addaleax

addaleax Oct 18, 2016

Member

CHECK_NE(env, nullptr);?

@addaleax

addaleax Oct 18, 2016

Member

CHECK_NE(env, nullptr);?

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

A CHECK won't hurt but OTOH, if it's a nullptr, the caller is going to find out soon enough. :-)

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

A CHECK won't hurt but OTOH, if it's a nullptr, the caller is going to find out soon enough. :-)

Show outdated Hide outdated src/env.h
@@ -503,6 +503,9 @@ class Environment {
inline v8::Local<v8::Object> NewInternalFieldObject();
inline void AtExit(void (*cb)(void* arg), void* arg);
inline void RunAtExit();

This comment has been minimized.

@addaleax

addaleax Oct 18, 2016

Member

RunAtExit was a confusing name when I first read it… I don’t have anything better in mind rn, but if you do, feel free to add that here.

@addaleax

addaleax Oct 18, 2016

Member

RunAtExit was a confusing name when I first read it… I don’t have anything better in mind rn, but if you do, feel free to add that here.

This comment has been minimized.

@danbev

danbev Oct 19, 2016

Member

How about RunAtExitCallbacks?

@danbev

danbev Oct 19, 2016

Member

How about RunAtExitCallbacks?

Show outdated Hide outdated src/node.h
@@ -209,7 +209,8 @@ NODE_EXTERN void FreeEnvironment(Environment* env);
NODE_EXTERN void EmitBeforeExit(Environment* env);
NODE_EXTERN int EmitExit(Environment* env);
NODE_EXTERN void RunAtExit(Environment* env);
NODE_DEPRECATED("Use Environment::RunAtExit()",
NODE_EXTERN void RunAtExit(Environment* env));

This comment has been minimized.

@addaleax

addaleax Oct 18, 2016

Member

Oh, one more thing: env.h is not a public header, so if anyone actually wants to use RunAtExit in an addon, deprecating this puts them in quite the difficult position. ;)

@addaleax

addaleax Oct 18, 2016

Member

Oh, one more thing: env.h is not a public header, so if anyone actually wants to use RunAtExit in an addon, deprecating this puts them in quite the difficult position. ;)

This comment has been minimized.

@danbev

danbev Oct 19, 2016

Member

Oh that does not sound good, I'll revert that :)

@danbev

danbev Oct 19, 2016

Member

Oh that does not sound good, I'll revert that :)

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Oct 18, 2016

Member

OS X CI failure: error: thread-local storage is not supported for the current target 😞 (output)

Maybe @bnoordhuis has a bit more context about who actually uses multiple Environments and in what way, I’ve always been wondering about that a bit.

Member

addaleax commented Oct 18, 2016

OS X CI failure: error: thread-local storage is not supported for the current target 😞 (output)

Maybe @bnoordhuis has a bit more context about who actually uses multiple Environments and in what way, I’ve always been wondering about that a bit.

Show outdated Hide outdated src/env-inl.h
p->arg_ = arg;
p->next_ = at_exit_functions_;
at_exit_functions_ = p;
}

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

These don't really need to be inlined. I'd move it to src/env.cc.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

These don't really need to be inlined. I'd move it to src/env.cc.

This comment has been minimized.

@danbev

danbev Oct 19, 2016

Member

Great, I'll move them.

@danbev

danbev Oct 19, 2016

Member

Great, I'll move them.

Show outdated Hide outdated src/node.cc
delete p;
p = q;
}
env->RunAtExit();

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

A CHECK won't hurt but OTOH, if it's a nullptr, the caller is going to find out soon enough. :-)

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

A CHECK won't hurt but OTOH, if it's a nullptr, the caller is going to find out soon enough. :-)

Show outdated Hide outdated src/node.cc
}
thread_local Environment* thread_local_env;

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

I'd leave out the = nullptr, it looks unidiomatic. It should be static though, yes.

@bnoordhuis

bnoordhuis Oct 18, 2016

Member

I'd leave out the = nullptr, it looks unidiomatic. It should be static though, yes.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Oct 18, 2016

Member

OS X CI failure: error: thread-local storage is not supported for the current target

Yeah, I was kind of expecting that. If we had still supported VS 2013, that would have been a problem, too. @danbev You can use uv_key_t instead.

Maybe @bnoordhuis has a bit more context about who actually uses multiple Environments and in what way, I’ve always been wondering about that a bit.

Embedders like electron and plask do. Electron for example has (or had) a context per tab.

Member

bnoordhuis commented Oct 18, 2016

OS X CI failure: error: thread-local storage is not supported for the current target

Yeah, I was kind of expecting that. If we had still supported VS 2013, that would have been a problem, too. @danbev You can use uv_key_t instead.

Maybe @bnoordhuis has a bit more context about who actually uses multiple Environments and in what way, I’ve always been wondering about that a bit.

Embedders like electron and plask do. Electron for example has (or had) a context per tab.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Oct 18, 2016

Member

Forgot to mention, the OS X issue could be fixed by linking to libc++ instead of libstdc++ but that has some wider ranging implications and would make the pull request unsuitable for back-porting to v4.x and v6.x.

EDIT: Scratch that, we already seem to be doing that in master? I see a -stdlib=libc++ in the arguments.

Member

bnoordhuis commented Oct 18, 2016

Forgot to mention, the OS X issue could be fixed by linking to libc++ instead of libstdc++ but that has some wider ranging implications and would make the pull request unsuitable for back-porting to v4.x and v6.x.

EDIT: Scratch that, we already seem to be doing that in master? I see a -stdlib=libc++ in the arguments.

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Oct 19, 2016

Member

@danbev You can use uv_key_t instead

I was not aware of uv_key_t, I'll take a look and try that out.

Member

danbev commented Oct 19, 2016

@danbev You can use uv_key_t instead

I was not aware of uv_key_t, I'll take a look and try that out.

@danbev

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

Looking at this again, it doesn't seem quite correct. The thread_local is set once but of course you can more than one Environment per isolate.

It's currently mostly academic because StartNodeInstance() is only called from Start() but still.

Show outdated Hide outdated src/env-inl.h
@@ -443,6 +443,7 @@ inline v8::Local<v8::Object> Environment::NewInternalFieldObject() {
return m_obj.ToLocalChecked();
}

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 20, 2016

Member

Unnecessary whitespace change.

@bnoordhuis

bnoordhuis Oct 20, 2016

Member

Unnecessary whitespace change.

This comment has been minimized.

@danbev

danbev Oct 20, 2016

Member

I'll remove this.

@danbev

danbev Oct 20, 2016

Member

I'll remove this.

Show outdated Hide outdated src/env.h
@@ -578,6 +581,9 @@ class Environment {
char* http_parser_buffer_;
struct AtExitCallback;
AtExitCallback* at_exit_functions_ = nullptr;

This comment has been minimized.

@bnoordhuis

bnoordhuis Oct 20, 2016

Member

For the record, I'd be okay with switching this a std::list<...>. Could be a separate commit or pull request.

@bnoordhuis

bnoordhuis Oct 20, 2016

Member

For the record, I'd be okay with switching this a std::list<...>. Could be a separate commit or pull request.

This comment has been minimized.

@danbev

danbev Oct 20, 2016

Member

Sounds good, let me do that in a separate PR.

@danbev

danbev Oct 20, 2016

Member

Sounds good, let me do that in a separate PR.

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Oct 20, 2016

Member

Looking at this again, it doesn't seem quite correct. The thread_local is set once but of course you can more than one Environment per isolate.

It's currently mostly academic because StartNodeInstance() is only called from Start() but still.

I'll take another look into this

Member

danbev commented Oct 20, 2016

Looking at this again, it doesn't seem quite correct. The thread_local is set once but of course you can more than one Environment per isolate.

It's currently mostly academic because StartNodeInstance() is only called from Start() but still.

I'll take another look into this

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Oct 25, 2016

Member

Rebased with upstream master.

Running CI again to see how much damage I've cause when updating node.gyp:
https://ci.nodejs.org/job/node-test-pull-request/4663/

This does not address @bnoordhuis point that Start can be called multiple times. I'll take a look at this next.

Member

danbev commented Oct 25, 2016

Rebased with upstream master.

Running CI again to see how much damage I've cause when updating node.gyp:
https://ci.nodejs.org/job/node-test-pull-request/4663/

This does not address @bnoordhuis point that Start can be called multiple times. I'll take a look at this next.

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Nov 3, 2016

Member

Looking at this again, it doesn't seem quite correct. The thread_local is set once but of course you can more than one Environment per isolate.

Sorry about the delay on this. I've tried to address the issue of having multiple Environments per Isolate for the use case when Node is being embedded (see 45248a4d5f1794174a44a56186c5d9266ff75087 for details).

I'm trying to understand the other case when node::Start would be called multiple times. I've started by trying to create a test that calls node::Start multiple times it but failed quite early. The error reported is:

$ make cctest GTEST_FILTER=NodeTest.*

Note: Google Test filter = NodeTest.*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from NodeTest
[ RUN      ] NodeTest.StartMultipleTimes


#
# Fatal error in ../deps/v8/src/v8.cc, line 94
# Check failed: !platform_.
#

==== C stack trace ===============================

    0   cctest                              0x0000000100325b4e v8::base::debug::StackTrace::StackTrace() + 30
    1   cctest                              0x0000000100325b85 v8::base::debug::StackTrace::StackTrace() + 21
    2   cctest                              0x000000010031e914 V8_Fatal + 452
    3   cctest                              0x00000001010c996d v8::internal::V8::InitializePlatform(v8::Platform*) + 77
    4   cctest                              0x000000010035e8e5 v8::V8::InitializePlatform(v8::Platform*) + 21
    5   cctest                              0x0000000100033b20 _ZN4node3$_010InitializeEi + 48
    6   cctest                              0x000000010003371e node::Start(int, char**) + 158
    7   cctest                              0x00000001000cee4f startNode(void*) + 31
    8   libsystem_pthread.dylib             0x00007fff8423a99d _pthread_body + 131
    9   libsystem_pthread.dylib             0x00007fff8423a91a _pthread_body + 0
    10  libsystem_pthread.dylib             0x00007fff84238351 thread_start + 13
make: *** [cctest] Illegal instruction: 4

I know @bnoordhuis said that it was mostly academic, and I'm wondering if this is worth pursuing?
I'd be happy to continue but feel I might need some help/guidance of the best way to move forward.

Also, adding a cctest that used Node core bits was interesting and took a while to get it to pass on all platforms. Would it make sense to clean up test: enable gtest that use node core code and add this separately or is there any policy to avoid cctest in favour of other tests?

Member

danbev commented Nov 3, 2016

Looking at this again, it doesn't seem quite correct. The thread_local is set once but of course you can more than one Environment per isolate.

Sorry about the delay on this. I've tried to address the issue of having multiple Environments per Isolate for the use case when Node is being embedded (see 45248a4d5f1794174a44a56186c5d9266ff75087 for details).

I'm trying to understand the other case when node::Start would be called multiple times. I've started by trying to create a test that calls node::Start multiple times it but failed quite early. The error reported is:

$ make cctest GTEST_FILTER=NodeTest.*

Note: Google Test filter = NodeTest.*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from NodeTest
[ RUN      ] NodeTest.StartMultipleTimes


#
# Fatal error in ../deps/v8/src/v8.cc, line 94
# Check failed: !platform_.
#

==== C stack trace ===============================

    0   cctest                              0x0000000100325b4e v8::base::debug::StackTrace::StackTrace() + 30
    1   cctest                              0x0000000100325b85 v8::base::debug::StackTrace::StackTrace() + 21
    2   cctest                              0x000000010031e914 V8_Fatal + 452
    3   cctest                              0x00000001010c996d v8::internal::V8::InitializePlatform(v8::Platform*) + 77
    4   cctest                              0x000000010035e8e5 v8::V8::InitializePlatform(v8::Platform*) + 21
    5   cctest                              0x0000000100033b20 _ZN4node3$_010InitializeEi + 48
    6   cctest                              0x000000010003371e node::Start(int, char**) + 158
    7   cctest                              0x00000001000cee4f startNode(void*) + 31
    8   libsystem_pthread.dylib             0x00007fff8423a99d _pthread_body + 131
    9   libsystem_pthread.dylib             0x00007fff8423a91a _pthread_body + 0
    10  libsystem_pthread.dylib             0x00007fff84238351 thread_start + 13
make: *** [cctest] Illegal instruction: 4

I know @bnoordhuis said that it was mostly academic, and I'm wondering if this is worth pursuing?
I'd be happy to continue but feel I might need some help/guidance of the best way to move forward.

Also, adding a cctest that used Node core bits was interesting and took a while to get it to pass on all platforms. Would it make sense to clean up test: enable gtest that use node core code and add this separately or is there any policy to avoid cctest in favour of other tests?

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Nov 11, 2016

Member

Can you squash into logical commits? I understand you made some additional changes but the history is kind of hard to follow.

Member

bnoordhuis commented Nov 11, 2016

Can you squash into logical commits? I understand you made some additional changes but the history is kind of hard to follow.

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Nov 11, 2016

Member

@bnoordhuis Sorry about that, most of them came about as I was trying to figure out how to get the test passing on the various platforms (after adding a test to cctest).

Member

danbev commented Nov 11, 2016

@bnoordhuis Sorry about that, most of them came about as I was trying to figure out how to get the test passing on the various platforms (after adding a test to cctest).

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Nov 16, 2016

Member

@bnoordhuis I've added some information to 8fde22b about the changes with regards to handling multiple Environments per isolate. The only files with changes related to this work are src/node.h, src/node.cc. The rest are just changes to get the test/cctest/test_environment.cc test running.

Member

danbev commented Nov 16, 2016

@bnoordhuis I've added some information to 8fde22b about the changes with regards to handling multiple Environments per isolate. The only files with changes related to this work are src/node.h, src/node.cc. The rest are just changes to get the test/cctest/test_environment.cc test running.

@bnoordhuis

I had to cut short the review but apropos the tests, I'd probably put them in test/addons so you don't have to reshuffle node.gyp so much.

Show outdated Hide outdated Makefile
@out/$(BUILDTYPE)/$@
@out/$(BUILDTYPE)/$@ --gtest_filter=$(GTEST_FILTER)
list-gtests: all

This comment has been minimized.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Can you add the target to the .PHONY list?

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Can you add the target to the .PHONY list?

This comment has been minimized.

@danbev

danbev Nov 21, 2016

Member

Absolutely, I'll add it.

@danbev

danbev Nov 21, 2016

Member

Absolutely, I'll add it.

Show outdated Hide outdated node.gyp
'NODE_PLATFORM="mac"',
],
'defines': [
# we need to use node's preferred "darwin" rather than gyp's preferred "mac"

This comment has been minimized.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Can you fix the long lines and the capitalization/punctuation while you're here?

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Can you fix the long lines and the capitalization/punctuation while you're here?

Show outdated Hide outdated node.gyp
],
'sources': [
'test/cctest/util.cc',
'<@(source_files)',

This comment has been minimized.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

I'm going to guess this means the files in src/ get built twice.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

I'm going to guess this means the files in src/ get built twice.

This comment has been minimized.

@danbev

danbev Nov 21, 2016

Member

Yeah unfortunately :( I was hoping that it would be possible to simply have a dependency to the <(node_core_target_name) target and not have to do this (or the other restructuring of common conditions and such into the targets_default). I'd be happy to take another stab at this if it is considered worthwhile to have these kinds of test in test/cctest. If not I'll take do as you suggested and put them in test/addons

@danbev

danbev Nov 21, 2016

Member

Yeah unfortunately :( I was hoping that it would be possible to simply have a dependency to the <(node_core_target_name) target and not have to do this (or the other restructuring of common conditions and such into the targets_default). I'd be happy to take another stab at this if it is considered worthwhile to have these kinds of test in test/cctest. If not I'll take do as you suggested and put them in test/addons

Show outdated Hide outdated node.gyp
'<@(source_files)',
'test/cctest/test_util.cc',
'test/cctest/test_environment.cc',
#'test/cctest/test_node.cc',

This comment has been minimized.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Don't leave commented-out code in.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Don't leave commented-out code in.

Show outdated Hide outdated test/cctest/node_test_fixture.cc
class NodeTestFixture : public ::testing::Test {
protected:

This comment has been minimized.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

No blank line and only one space indent for the protected: keyword.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

No blank line and only one space indent for the protected: keyword.

Show outdated Hide outdated test/cctest/test_environment.cc
static bool called_cb_2 = false;
static void at_exit_callback1(void* arg);
static void at_exit_callback2(void* arg);
static Environment* newEnv(node::IsolateData* isolateData, v8::Local<v8::Context> context);

This comment has been minimized.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Long line and no camel-casing.

@bnoordhuis

bnoordhuis Nov 16, 2016

Member

Long line and no camel-casing.

@danbev

This comment has been minimized.

Show comment
Hide comment
Member

danbev commented Mar 14, 2017

@bnoordhuis

Left some comments. Nice work on the tests.

Show outdated Hide outdated node.gyp
'<(PRODUCT_DIR)/obj.target/node/src/tracing/agent.o',
'<(PRODUCT_DIR)/obj.target/node/src/tracing/node_trace_buffer.o',
'<(PRODUCT_DIR)/obj.target/node/src/tracing/node_trace_writer.o',
'<(PRODUCT_DIR)/obj.target/node/src/tracing/trace_event.o',

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

You should use <(OBJ_DIR)/node/src/... here. The directory is different when building with ninja (and VS too, probably.)

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

You should use <(OBJ_DIR)/node/src/... here. The directory is different when building with ninja (and VS too, probably.)

This comment has been minimized.

@danbev

danbev Mar 14, 2017

Member

Ah I see. I'll fix that.

@danbev

danbev Mar 14, 2017

Member

Ah I see. I'll fix that.

This comment has been minimized.

@danbev

danbev Mar 15, 2017

Member

I tried this out but it did not work for me as the object files could not be found using OBJ_DIR. I created #11857, can you take a look and see what you think about it?

@danbev

danbev Mar 15, 2017

Member

I tried this out but it did not work for me as the object files could not be found using OBJ_DIR. I created #11857, can you take a look and see what you think about it?

Show outdated Hide outdated node.gyp
}]]
}, {
'defines': [ 'HAVE_OPENSSL=0' ]
}],

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

That's an awful amount of duplication... There is probably a better way, like moving it into a node.gypi file and including that.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

That's an awful amount of duplication... There is probably a better way, like moving it into a node.gypi file and including that.

This comment has been minimized.

@danbev

danbev Mar 14, 2017

Member

I think it could be put into a target_defaults if that would be acceptable?

@danbev

danbev Mar 14, 2017

Member

I think it could be put into a target_defaults if that would be acceptable?

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

If it works, sure. Don't put it in common.gypi though (which has a target_defaults section), see nodejs/node-gyp#1118 for rationale.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

If it works, sure. Don't put it in common.gypi though (which has a target_defaults section), see nodejs/node-gyp#1118 for rationale.

Show outdated Hide outdated test/cctest/node_test_fixture.cc
int prog_len = strlen(prog) + 1;
int arg1_len = strlen(arg1) + 1;
int arg2_len = strlen(arg2) + 1;
char **argv = reinterpret_cast<char**>(malloc(3 * sizeof(char*)));

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Style: char** argv and you can probably static_cast here.

I'd encapsulate this in a RAII class so you don't have to free manually. As well, if you have a fixed number of arguments, I'd do something like this:

struct Argv {
  Argv(const char* a, const char* b, const char* c)
      : a_(a), b_(b), c_(c) {
    vec_[0] = a_.c_str();
    vec_[1] = b_.c_str();
    vec_[2] = c_.c_str();
    vec_[3] = nullptr;
  }

  char* vec_[4];
  std::string a_;
  std::string b_;
  std::string c_;
};
@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Style: char** argv and you can probably static_cast here.

I'd encapsulate this in a RAII class so you don't have to free manually. As well, if you have a fixed number of arguments, I'd do something like this:

struct Argv {
  Argv(const char* a, const char* b, const char* c)
      : a_(a), b_(b), c_(c) {
    vec_[0] = a_.c_str();
    vec_[1] = b_.c_str();
    vec_[2] = c_.c_str();
    vec_[3] = nullptr;
  }

  char* vec_[4];
  std::string a_;
  std::string b_;
  std::string c_;
};

This comment has been minimized.

@danbev

danbev Mar 14, 2017

Member

I like that, very nice.

@danbev

danbev Mar 14, 2017

Member

I like that, very nice.

Show outdated Hide outdated test/cctest/node_test_fixture.h
@@ -0,0 +1,60 @@
#ifndef TEST_CCTEST_NODE_TEST_FIXTURE_H_
#define TEST_CCTEST_NODE_TEST_FIXTURE_H_
#include "gtest/gtest.h"

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Style: blank line before the first include.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Style: blank line before the first include.

Show outdated Hide outdated test/cctest/node_test_fixture.h
virtual void* Allocate(size_t length) {
void* data = AllocateUninitialized(length);
return data == NULL ? data : memset(data, 0, length);
}

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Indent errors. FWIW, I'd just implement AllocateUninitialized() in terms of calloc() and do away with the memset() here.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Indent errors. FWIW, I'd just implement AllocateUninitialized() in terms of calloc() and do away with the memset() here.

This comment has been minimized.

@danbev

danbev Mar 14, 2017

Member

I'll take a look at that. I really just copied that from somewhere.

@danbev

danbev Mar 14, 2017

Member

I'll take a look at that. I really just copied that from somewhere.

Show outdated Hide outdated test/cctest/test_util.cc
namespace node {
void LowMemoryNotification() {}
}

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Intentional change? (I'm guessing yes, conflict with the function from util.cc?)

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

Intentional change? (I'm guessing yes, conflict with the function from util.cc?)

This comment has been minimized.

@danbev

danbev Mar 14, 2017

Member

Yeah, it was intentional and just like you said it conflicts with the function from util.cc. Any better way around that you can think of?

@danbev

danbev Mar 14, 2017

Member

Yeah, it was intentional and just like you said it conflicts with the function from util.cc. Any better way around that you can think of?

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

No, this is fine. I was just curious.

@bnoordhuis

bnoordhuis Mar 14, 2017

Member

No, this is fine. I was just curious.

Show outdated Hide outdated test/cctest/node_test_fixture.h
const char* arg1,
const char* arg2);
static void freeargv(char** argv);
Argv(const char* prog, const char* arg1, const char* arg2) {

This comment has been minimized.

@danbev

danbev Mar 15, 2017

Member

@bnoordhuis This not what you suggested but I'm going to try it the way you suggested. Previously I had issue on other platforms (than mac) where memory allocation for argv was not continuous leading to an error in libuv. But like I said I'll take a stab at this again.

@danbev

danbev Mar 15, 2017

Member

@bnoordhuis This not what you suggested but I'm going to try it the way you suggested. Previously I had issue on other platforms (than mac) where memory allocation for argv was not continuous leading to an error in libuv. But like I said I'll take a stab at this again.

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Mar 17, 2017

Member

@bnoordhuis Would you mind doing another review? Sorry about the number of commit here, I had some issues with various operating systems to get the test to pass. But they should all be green now.

I can create separate pull requests for some of these, for example c4097dd, so that this pull request is more focused on what it is supposed to be fixing?

Member

danbev commented Mar 17, 2017

@bnoordhuis Would you mind doing another review? Sorry about the number of commit here, I had some issues with various operating systems to get the test to pass. But they should all be green now.

I can create separate pull requests for some of these, for example c4097dd, so that this pull request is more focused on what it is supposed to be fixing?

Show outdated Hide outdated test/cctest/node_test_fixture.h
}
virtual void* AllocateUninitialized(size_t length) {
return calloc(length, sizeof(int));

This comment has been minimized.

@addaleax

addaleax Mar 20, 2017

Member

sizeof(int)? Is that a typo or intentional?

@addaleax

addaleax Mar 20, 2017

Member

sizeof(int)? Is that a typo or intentional?

This comment has been minimized.

@danbev

danbev Mar 21, 2017

Member

Actually not a typo but that does not mean it is correct :)
When reading the documentation for calloc the size argument takes a size_t and I though sizeof would be appropriate. Are there better/correct ways of doing this?

@danbev

danbev Mar 21, 2017

Member

Actually not a typo but that does not mean it is correct :)
When reading the documentation for calloc the size argument takes a size_t and I though sizeof would be appropriate. Are there better/correct ways of doing this?

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 21, 2017

Member

calloc(length, 1) - sizeof(int) allocates 4x more than requested.

(1 because sizeof(char) == 1 by definition, it's the smallest addressable unit.)

@bnoordhuis

bnoordhuis Mar 21, 2017

Member

calloc(length, 1) - sizeof(int) allocates 4x more than requested.

(1 because sizeof(char) == 1 by definition, it's the smallest addressable unit.)

This comment has been minimized.

@danbev

danbev Mar 21, 2017

Member

Ah got it. Thanks @bnoordhuis, @addaleax

@danbev

danbev Mar 21, 2017

Member

Ah got it. Thanks @bnoordhuis, @addaleax

Show outdated Hide outdated test/cctest/node_test_fixture.h
int arg1_len = strlen(arg1) + 1;
int arg2_len = strlen(arg2) + 1;
argv_ = static_cast<char**>(malloc(3 * sizeof(char*)));
argv_[0] = reinterpret_cast<char*>(malloc(prog_len + arg1_len + arg2_len));

This comment has been minimized.

@addaleax

addaleax Mar 20, 2017

Member

static_cast?

@addaleax

addaleax Mar 20, 2017

Member

static_cast?

This comment has been minimized.

@danbev

danbev Mar 21, 2017

Member

Ah yes, I should have changed both but missed that. Thanks

@danbev

danbev Mar 21, 2017

Member

Ah yes, I should have changed both but missed that. Thanks

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Mar 20, 2017

Member

@danbev I think splitting the PR might be a good idea where it makes sense, otherwise @bnoordhuis might be the only person around here capable of giving this a full review ;)

Member

addaleax commented Mar 20, 2017

@danbev I think splitting the PR might be a good idea where it makes sense, otherwise @bnoordhuis might be the only person around here capable of giving this a full review ;)

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Mar 21, 2017

Member

@addaleax Yeah I agree, I'll create a separate PR for the changes made to get the tests working.

Member

danbev commented Mar 21, 2017

@addaleax Yeah I agree, I'll create a separate PR for the changes made to get the tests working.

danbev added a commit to danbev/node that referenced this pull request Mar 21, 2017

build: enable cctest to use generated objects
This commit tries to make it simpler to add unit tests (cctest) for
code that needs to test node core funtionality but that might not be
appropriate as an addon or a JavaScript test. An example of this could
be adding functionality targeted for situations when Node itself is
embedded.

Currently it was not as easy, or efficient, as one would have hoped to
add such tests. The object output directories vary for different
operating systems which we need to link to so that we don't have an
additional compilation step.

Refs: nodejs#9163

@danbev danbev referenced this pull request Mar 21, 2017

Closed

build: enable cctest to use generated objects #11956

2 of 2 tasks complete
@danbev

This comment has been minimized.

Show comment
Hide comment

jasnell added a commit that referenced this pull request Mar 24, 2017

build: enable cctest to use generated objects
This commit tries to make it simpler to add unit tests (cctest) for
code that needs to test node core funtionality but that might not be
appropriate as an addon or a JavaScript test. An example of this could
be adding functionality targeted for situations when Node itself is
embedded.

Currently it was not as easy, or efficient, as one would have hoped to
add such tests. The object output directories vary for different
operating systems which we need to link to so that we don't have an
additional compilation step.

PR-URL: #11956
Ref: #9163
Reviewed-By: James M Snell <jasnell@gmail.com>

jasnell added a commit that referenced this pull request Mar 24, 2017

doc: c++ unit test guide lines
PR-URL: #11956
Ref: #9163
Reviewed-By: James M Snell <jasnell@gmail.com>
@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Mar 26, 2017

Member

@danbev Can you rebase this? :)

Member

addaleax commented Mar 26, 2017

@danbev Can you rebase this? :)

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Mar 26, 2017

Member

@addaleax done :) I noticed that I've included the now empty node_test_fixture.cc which is also listed in node.gyp. I'll fix this tomorrow or this evening.

CI: https://ci.nodejs.org/job/node-test-pull-request/7040/

Member

danbev commented Mar 26, 2017

@addaleax done :) I noticed that I've included the now empty node_test_fixture.cc which is also listed in node.gyp. I'll fix this tomorrow or this evening.

CI: https://ci.nodejs.org/job/node-test-pull-request/7040/

@danbev

This comment has been minimized.

Show comment
Hide comment

refack added a commit to refack/node that referenced this pull request May 16, 2017

build: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs#11956
Original-Ref: nodejs#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#12450
Reviewed-By: João Reis <reis@janeasystems.com>

@jasnell jasnell referenced this pull request May 11, 2017

Closed

8.0.0 Release Proposal #12220

danbev added a commit to danbev/node that referenced this pull request May 30, 2017

build: enable cctest to use generated objects
This commit tries to make it simpler to add unit tests (cctest) for
code that needs to test node core funtionality but that might not be
appropriate as an addon or a JavaScript test. An example of this could
be adding functionality targeted for situations when Node itself is
embedded.

Currently it was not as easy, or efficient, as one would have hoped to
add such tests. The object output directories vary for different
operating systems which we need to link to so that we don't have an
additional compilation step.

PR-URL: nodejs#11956
Ref: nodejs#9163
Reviewed-By: James M Snell <jasnell@gmail.com>

gibfahn added a commit to gibfahn/node that referenced this pull request Jun 17, 2017

build: enable cctest to use generated objects
This commit tries to make it simpler to add unit tests (cctest) for
code that needs to test node core funtionality but that might not be
appropriate as an addon or a JavaScript test. An example of this could
be adding functionality targeted for situations when Node itself is
embedded.

Currently it was not as easy, or efficient, as one would have hoped to
add such tests. The object output directories vary for different
operating systems which we need to link to so that we don't have an
additional compilation step.

PR-URL: nodejs#11956
Backport-PR-URL: nodejs#12948
Ref: nodejs#9163
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Jul 11, 2017

build: enable cctest to use generated objects
This commit tries to make it simpler to add unit tests (cctest) for
code that needs to test node core funtionality but that might not be
appropriate as an addon or a JavaScript test. An example of this could
be adding functionality targeted for situations when Node itself is
embedded.

Currently it was not as easy, or efficient, as one would have hoped to
add such tests. The object output directories vary for different
operating systems which we need to link to so that we don't have an
additional compilation step.

PR-URL: #11956
Backport-PR-URL: #12948
Ref: #9163
Reviewed-By: James M Snell <jasnell@gmail.com>

sam-github pushed a commit to sam-github/node that referenced this pull request Jul 12, 2017

build: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs#11956
Original-Ref: nodejs#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#12450
Reviewed-By: João Reis <reis@janeasystems.com>

sam-github pushed a commit to sam-github/node that referenced this pull request Jul 18, 2017

build: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs#11956
Original-Ref: nodejs#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#12450
Reviewed-By: João Reis <reis@janeasystems.com>

refack added a commit to refack/node that referenced this pull request Jul 18, 2017

build: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs#11956
Original-Ref: nodejs#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#12450
Reviewed-By: João Reis <reis@janeasystems.com>

andrew749 added a commit to michielbaird/node that referenced this pull request Jul 19, 2017

src: use std::list for at_exit_functions
This change was suggested by bnoordhuis in the following comment:
nodejs/node#9163 (comment)

Not including any tests as this is covered by test/addons/at-exit.

PR-URL: nodejs/node#12255
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>

refack added a commit to refack/node that referenced this pull request Aug 9, 2017

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs#11956
Original-Ref: nodejs#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#12450
Reviewed-By: João Reis <reis@janeasystems.com>

refack added a commit to refack/node that referenced this pull request Aug 19, 2017

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs#11956
Original-Ref: nodejs#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#12450
Reviewed-By: João Reis <reis@janeasystems.com>

refack added a commit to refack/node that referenced this pull request Aug 23, 2017

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs#11956
Original-Ref: nodejs#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#12450
Reviewed-By: João Reis <reis@janeasystems.com>

addaleax added a commit to addaleax/ayo that referenced this pull request Aug 25, 2017

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs/node#11956
Original-Ref: nodejs/node#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs/node#12450
Reviewed-By: João Reis <reis@janeasystems.com>

addaleax added a commit to ayojs/ayo that referenced this pull request Aug 28, 2017

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs/node#11956
Original-Ref: nodejs/node#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs/node#12450
Reviewed-By: João Reis <reis@janeasystems.com>

MylesBorins added a commit that referenced this pull request Sep 10, 2017

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: #11956
Original-Ref: #9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: #12450
Reviewed-By: João Reis <reis@janeasystems.com>

MylesBorins added a commit that referenced this pull request Sep 12, 2017

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: #11956
Original-Ref: #9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: #12450
Reviewed-By: João Reis <reis@janeasystems.com>
@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Sep 19, 2017

Member

For right now @nodejs/lts decided to not land this as we didn't see a specific reason to backport. If this may be mistaken please let us know

Member

MylesBorins commented Sep 19, 2017

For right now @nodejs/lts decided to not land this as we didn't see a specific reason to backport. If this may be mistaken please let us know

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Jan 17, 2018

Member

Looks like this causes an issue with electron, see electron/electron#11299 (comment).

I don't know enough about this PR to be able to comment on whether the solution proposed in that thread is a good idea or not, but maybe @danbev @addaleax or @bnoordhuis might be able to offer some advice there.

Member

gibfahn commented Jan 17, 2018

Looks like this causes an issue with electron, see electron/electron#11299 (comment).

I don't know enough about this PR to be able to comment on whether the solution proposed in that thread is a good idea or not, but maybe @danbev @addaleax or @bnoordhuis might be able to offer some advice there.

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Jan 18, 2018

Member

@gibfahn I'll take a closer look at this (hopefully later today or tomorrow).

Member

danbev commented Jan 18, 2018

@gibfahn I'll take a closer look at this (hopefully later today or tomorrow).

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Jan 22, 2018

Member

I've started to look into this, but won't be working for the next few (sick kid), but I'll revisit as soon as I'm back.

Member

danbev commented Jan 22, 2018

I've started to look into this, but won't be working for the next few (sick kid), but I'll revisit as soon as I'm back.

danbev added a commit to danbev/node that referenced this pull request Feb 5, 2018

src: set thread local env in CreateEnvironment
This commit set the Environment as a thread local when CreateEnvironment
is called which is currently not being done. This would lead to a
segment fault if later node::AtExit is called without specifying the
environment parameter. This specific issue was reported by Electron.

If I recall correctly, back when this was implemented the motivation was
that if embedders have multiple environments per isolate they should be
using the AtExit functions that take an environment. This is not the
case with Electron which only create a single environment (as far as I
know), and if a native module calls AtExit this would lead to the
segment fault.

I was able to reproduce Electron issue and the provided test simulates
it. I was also able to use this patch and verify that it works for the
Electron issue as well.

Refs: nodejs#9163
Refs: electron/electron#11299

@danbev danbev referenced this pull request Feb 5, 2018

Closed

src: set thread local env in CreateEnvironment #18573

3 of 3 tasks complete

danbev added a commit to danbev/node that referenced this pull request Feb 13, 2018

src: set thread local env in CreateEnvironment
This commit set the Environment as a thread local when CreateEnvironment
is called which is currently not being done. This would lead to a
segment fault if later node::AtExit is called without specifying the
environment parameter. This specific issue was reported by Electron.

If I recall correctly, back when this was implemented the motivation was
that if embedders have multiple environments per isolate they should be
using the AtExit functions that take an environment. This is not the
case with Electron which only create a single environment (as far as I
know), and if a native module calls AtExit this would lead to the
segment fault.

I was able to reproduce Electron issue and the provided test simulates
it. I was also able to use this patch and verify that it works for the
Electron issue as well.

Refs: nodejs#9163
Refs: electron/electron#11299

danbev added a commit to danbev/node that referenced this pull request Feb 16, 2018

src: set thread local env in CreateEnvironment
This commit set the Environment as a thread local when CreateEnvironment
is called which is currently not being done. This would lead to a
segment fault if later node::AtExit is called without specifying the
environment parameter. This specific issue was reported by Electron.

If I recall correctly, back when this was implemented the motivation was
that if embedders have multiple environments per isolate they should be
using the AtExit functions that take an environment. This is not the
case with Electron which only create a single environment (as far as I
know), and if a native module calls AtExit this would lead to the
segment fault.

I was able to reproduce Electron issue and the provided test simulates
it. I was also able to use this patch and verify that it works for the
Electron issue as well.

PR-URL: nodejs#18573
Refs: nodejs#9163
Refs: electron/electron#11299
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matheus Marchini <matheus@sthima.com>

BridgeAR added a commit to BridgeAR/node that referenced this pull request May 1, 2018

src: set thread local env in CreateEnvironment
This commit set the Environment as a thread local when CreateEnvironment
is called which is currently not being done. This would lead to a
segment fault if later node::AtExit is called without specifying the
environment parameter. This specific issue was reported by Electron.

If I recall correctly, back when this was implemented the motivation was
that if embedders have multiple environments per isolate they should be
using the AtExit functions that take an environment. This is not the
case with Electron which only create a single environment (as far as I
know), and if a native module calls AtExit this would lead to the
segment fault.

I was able to reproduce Electron issue and the provided test simulates
it. I was also able to use this patch and verify that it works for the
Electron issue as well.

PR-URL: nodejs#18573
Refs: nodejs#9163
Refs: electron/electron#11299
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matheus Marchini <matheus@sthima.com>

MayaLekova added a commit to MayaLekova/node that referenced this pull request May 8, 2018

src: set thread local env in CreateEnvironment
This commit set the Environment as a thread local when CreateEnvironment
is called which is currently not being done. This would lead to a
segment fault if later node::AtExit is called without specifying the
environment parameter. This specific issue was reported by Electron.

If I recall correctly, back when this was implemented the motivation was
that if embedders have multiple environments per isolate they should be
using the AtExit functions that take an environment. This is not the
case with Electron which only create a single environment (as far as I
know), and if a native module calls AtExit this would lead to the
segment fault.

I was able to reproduce Electron issue and the provided test simulates
it. I was also able to use this patch and verify that it works for the
Electron issue as well.

PR-URL: nodejs#18573
Refs: nodejs#9163
Refs: electron/electron#11299
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matheus Marchini <matheus@sthima.com>

maclover7 added a commit to maclover7/node-gyp that referenced this pull request Jul 31, 2018

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69ec9d36b705e9bde2ac1a193566a702d96
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs/node#11956
Original-Ref: nodejs/node#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs/node#12450
Reviewed-By: João Reis <reis@janeasystems.com>

rvagg added a commit to nodejs/node-gyp that referenced this pull request Aug 9, 2018

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69ec9d36b705e9bde2ac1a193566a702d96
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs/node#11956
Original-Ref: nodejs/node#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs/node#12450
Reviewed-By: João Reis <reis@janeasystems.com>

rvagg added a commit to nodejs/node-gyp that referenced this pull request Aug 9, 2018

gyp: enable cctest to use objects (gyp part)
this is a re-base of the gyp part of
6a09a69ec9d36b705e9bde2ac1a193566a702d96
after bumping GYP version to
https://chromium.googlesource.com/external/gyp/+/eb296f67da078ec01f5e3a9ea9cdc6d26d680161

Original-PR-URL: nodejs/node#11956
Original-Ref: nodejs/node#9163
Original-Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs/node#12450
Reviewed-By: João Reis <reis@janeasystems.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment