-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
flaky test-inspector-connect-main-thread #31226
Comments
Crash on freebsd: 01:28:58 not ok 1248 parallel/test-inspector-connect-main-thread
01:28:58 ---
01:28:58 duration_ms: 1.289
01:28:58 severity: crashed
01:28:58 exitcode: -6
01:28:58 stack: |-
01:28:58 Skip child is done
01:28:58 Message for a test
01:28:58 Worker is done
01:28:58 Message NodeWorker.enable was sent
01:28:58 Message Debugger.enable was sent
01:28:58 Message Runtime.enable was sent
01:28:58 Message Debugger.setBreakpointByUrl was sent
01:28:58 Message Debugger.evaluateOnCallFrame was sent
01:28:58 Message Debugger.resume was sent
01:28:58 out/Release/node[37608]: ../src/api/callback.cc:147:MaybeLocal<v8::Value> node::InternalMakeCallback(node::Environment *, Local<v8::Object>, const Local<v8::Function>, int, Local<v8::Value> *, node::async_context): Assertion `!recv.IsEmpty()' failed.
01:28:58 1: 0x9d8f60 node::Abort(void) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 2: 0x9d8d19 node::Assert(node::AssertionInfo const&) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 3: 0x937e27 v8<node::Environment*::Function> node::InternalMakeCallback(node::Environment*, v8::Local<node::Environment*::Object>(int, v8<node::Environment*::Value>*, node::async_context) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 4: 0x9491d1 int node::AsyncWrap::MakeCallback(v8::Local<node::AsyncWrap::MakeCallback::Function>(v8<node::AsyncWrap::MakeCallback::Value>*) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 5: 0xaa1fe4 _register_inspector(void) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 6: 0xaa966b node::inspector::MainThreadInterface::DispatchMessages(void) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 7: 0xaaabae node::inspector::MainThreadHandle::Expired(void) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 8: 0xa420e2 node::PerIsolatePlatformData::RunForegroundTask(std::__1::unique_ptr<v8::Task, node::PerIsolatePlatformData::RunForegroundTask::default_delete<v8> >) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 9: 0xa40b03 node::PerIsolatePlatformData::FlushForegroundTasksInternal(void) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 10: 0xa423d1 node::NodePlatform::DrainTasks(v8::Isolate*) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 11: 0xa671a8 node::worker::Worker::Run(void) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 12: 0xa68e25 _register_worker(void) [/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/node]
01:28:58 13: 0x805103c06 operator-> [/lib/libthr.so.3]
01:28:58 ... |
With a relatively-recent debug build and running
|
/ping @addaleax @joyeecheung The relevant Prior to that, the |
Failed on
|
Previously, the test waited for a (any) message from the workers, and then attached another event listener to a specific kind of message. However, it was possible that the second listener was attached after the Worker had already exited, thus never receiving the message it was supposed to receive. (This is the race condition here – usually, the Worker thread would exit *after* the second listener was attached.) Solve this by keeping a single `'message'` event listener attached to the worker instance during its entire lifetime. Fixes: nodejs#31226
Previously, the test waited for a (any) message from the workers, and then attached another event listener to a specific kind of message. However, it was possible that the second listener was attached after the Worker had already exited, thus never receiving the message it was supposed to receive. (This is the race condition here – usually, the Worker thread would exit *after* the second listener was attached.) Solve this by keeping a single `'message'` event listener attached to the worker instance during its entire lifetime. Fixes: #31226 PR-URL: #31637 Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Previously, the test waited for a (any) message from the workers, and then attached another event listener to a specific kind of message. However, it was possible that the second listener was attached after the Worker had already exited, thus never receiving the message it was supposed to receive. (This is the race condition here – usually, the Worker thread would exit *after* the second listener was attached.) Solve this by keeping a single `'message'` event listener attached to the worker instance during its entire lifetime. Fixes: #31226 PR-URL: #31637 Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Previously, the test waited for a (any) message from the workers, and then attached another event listener to a specific kind of message. However, it was possible that the second listener was attached after the Worker had already exited, thus never receiving the message it was supposed to receive. (This is the race condition here – usually, the Worker thread would exit *after* the second listener was attached.) Solve this by keeping a single `'message'` event listener attached to the worker instance during its entire lifetime. Fixes: #31226 PR-URL: #31637 Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Previously, the test waited for a (any) message from the workers, and then attached another event listener to a specific kind of message. However, it was possible that the second listener was attached after the Worker had already exited, thus never receiving the message it was supposed to receive. (This is the race condition here – usually, the Worker thread would exit *after* the second listener was attached.) Solve this by keeping a single `'message'` event listener attached to the worker instance during its entire lifetime. Fixes: #31226 PR-URL: #31637 Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Node daily failed, looks like a SIGSEGV:
The text was updated successfully, but these errors were encountered: