Segmentation fault (core dumped) - Debug on Ubuntu

[bknill]

Hi,

I'm getting a crash with an error message

Segmentation fault (core dumped)

Is there anyway to debug this?

Thanks

[avaer]

Yes, you can use gdb with node to get a backtrace (bt) to see what's hanging it up.

[bknill]

Sorry @modulesio I've been trying to get this running on Ubuntu but it's failing because of the Node version check doesn't appear to return what you need in index line 3.

Break on start in file:///home/owner/workspace/client/exokit/src/index.js:3
1
2

3 if (require.main === module && !/^1[12]./.test(process.versions.node)) {
4 throw new Error('node 11 or 12 required');
5 }

Do you know how to get this running?

[avaer]

Node 12 is required before building.

On Ubuntu, the best way to get the right version of node is probably https://github.com/nvm-sh/nvm.

[bknill]

Yes I have node 12. Exokit is running normally just crashing with the above error. I've had it running my app before, just can't find what the problem is right now.

[avaer]

Interesting, when you run node what do you get with:

process.versions.node

[bknill]

Hmm this is with node inspect which is throwing errors when I try and console log that.

Bit new to node.

[avaer]

You can just run node regularly with node, which will give you a CLI. Then you can log what the version of node is. (we're trying to figure out why, if you have node 12, that check is failing)

[bknill]

Running 12.2.0

[avaer]

Oh wait, are we simply running everything in node inspect without continuing the breakpoint? Then the node inspector is probably just waiting for continue in the interface.

Either way, to debug a segfault we would need gdb (not node inspect).

gdb node
run . /home/owner/workspace/client/exokit/src/index.js
c
bt

Or similar.

[bknill]

Yes! Sorry found it.. just had to type run and I'm off.

Found the error - relates to the Redux websocket connection to the debugger.

Have now found another load of errors which I'll try and fix. Thanks

[avaer]

Awesome, let us know if you get stuck!

[bknill]

Ha yep stuck!

This error:

Thread 12 "node" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd7fe8700 (LWP 21194)]
0x00000000040fc360 in ?? ()

This from the backtrace

#0  0x00000000040fc360 in ?? ()
#1  0x00007fffde249d27 in glfwMakeContextCurrent () from /home/owner/workspace/client/exokit/build/Release/exokit.node
#2  0x00007fffde1f692a in glfw::SetCurrentWindowContext(GLFWwindow*) () from /home/owner/workspace/client/exokit/build/Release/exokit.node
#3  0x00007fffde1f6be5 in glfw::InitWindow2D(Nan::FunctionCallbackInfo<v8::Value> const&) () from /home/owner/workspace/client/exokit/build/Release/exokit.node
#4  0x00007fffde1f0fbf in Nan::imp::FunctionCallbackWrapper () from /home/owner/workspace/client/exokit/build/Release/exokit.node
#5  0x0000000000b8ed76 in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) ()
#6  0x0000000000b90c89 in v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) ()
#7  0x0000000001a86142 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit () at ../../deps/v8/src/builtins/base.tq:1866
#8  0x00000000019f05c4 in Builtins_InterpreterEntryTrampoline () at ../../deps/v8/src/builtins/base.tq:107

Mean anything?

[avaer]

It means that something is wrong with the OpenGL context creation, since it cannot switch to the context that was made.

Do you have a reproduction HTML file for this?

[bknill]

No sorry. It's just local at the moment. I'll try and get a build done to a test host.

It's opening 2 Exokit windows, is that correct?

And it's running some of the time.

[avaer]

I can't tell from that stack trace alone what the issue is, but Exokit opens one window for every context, depending on visibility.

If you could get any kind of HTML reproduction that crashes on the system, that would be helpful for debugging.

It could very well be a race condition.