Upgrade to node 0.10.x segfaults #16

Closed
jeffwad opened this Issue Apr 2, 2013 · 25 comments

10 participants

@jeffwad

Hi,

I've just upgraded to node 0.10. from the last stable 0.8 release. Node midi now, sadly, segfaults when required.

I've done the obvious (to my mind), and rebuilt/reinstalled it; but to no avail. I tried giving it a go with this (https://github.com/ddopson/node-segfault-handler) but haven't had any luck getting any output yet. I'll be having another go as soon as I have time.

I'm no node expert, so If there is something I should have done ready for release 0.10 I'd be happy to do it if I knew what it was.

Cheers

Si

@justinlatimer

If you've done npm rebuild after upgrading and you're getting the problem, then it's a bug. I'll look at it as soon as I can (not sure when that will be).

@maxmechanic

I was getting a "Bus error: 10" (which from SO-searching seems to be related to segmentation errors) message running the most recent stable 0.10 release and saw this issue, so I've tried downgrading to 8.5 and 8.9 and got more explicit segfaults.

In case it's helpful, these were my logs from doing a rebuild:

0.8.5:

In file included from ../src/node-midi.cpp:8:
../src/lib/RtMidi/RtMidi.cpp:473:26: warning: implicit conversion of NULL
      constant to 'MIDIEntityRef' (aka 'unsigned int') [-Wnull-conversion]
  MIDIEntityRef entity = NULL; 

0.8.9:

../src/lib/RtMidi/RtMidi.cpp:473:26: warning: implicit conversion of NULL
      constant to 'MIDIEntityRef' (aka 'unsigned int') [-Wnull-conversion]
  MIDIEntityRef entity = NULL;

0.10.5:

../src/lib/RtMidi/RtMidi.cpp:473:26: warning: implicit conversion of NULL
      constant to 'MIDIEntityRef' (aka 'unsigned int') [-Wnull-conversion]
  MIDIEntityRef entity = NULL;
@justinlatimer
@ghost Unknown referenced this issue Jun 21, 2013
Closed

problem installing module #25

@ghost
@carlos8f

same problem here :(

@contra

I don't get a segfault if I npm install (it just fails silently) but when cloning and trying to run the tests it does. Here is the stack

Don-Juan-PC:node-midi contra$ node test/input-test.js
PID 72640 received SIGSEGV for address: 0x11
0   segfault_handler.node               0x0000000100afdb8b _ZL16segfault_handleriP9__siginfoPv + 191
1   libsystem_c.dylib                   0x00007fff865f194a _sigtramp + 26
2   CoreMIDI                            0x0000000101952350 _ZL17_BootAbsoluteTime + 11872
3   midi.node                           0x0000000100fea05f _ZN13NodeMidiInput3NewERKN2v89ArgumentsE + 85
4   node                                0x0000000100170750 _ZN2v88internalL30Builtin_HandleApiCallConstructENS0_12_GLOBAL__N_116BuiltinArgumentsILNS0_21BuiltinExtraArgumentsE1EEEPNS0_7IsolateE + 544
5   ???                                 0x00001babda70618e 0x0 + 30424918155662
6   ???                                 0x00001babda7244d7 0x0 + 30424918279383
@vkoop

I also get a segmentation fault when i try to run test/input-test.js.

I would really love to the module! I'm using node v0.10.13

@randallagordon

On Ubuntu 12.04 I'm getting segfaults with node v0.10.12 but not with v0.10.8.

@uberscientist

I'm getting a segfault with node v0.10.21 at this line: var input = new midi.input(); -- I am able to require the module without any apparent problems.

I'll poke around and see if I can figure anything out...

@drewish
Collaborator

So on OS X 10.9 and Node 0.10.22 my stack trace looked like:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   node                            0x0000000100125cf7 uv_unref + 32
1   midi.node                       0x00000001009e41a5 NodeMidiInput::New(v8::Arguments const&) + 85 (v8.h:4297)
2   node                            0x00000001001662c4 v8::internal::Builtin_HandleApiCallConstruct(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*) + 512
3   ???                             0x00003c0778f0618e 0 + 66002791457166

The relevant section of the source:

    static v8::Handle<v8::Value> New(const v8::Arguments& args)
    {
        v8::HandleScope scope;
        NodeMidiInput* input = new NodeMidiInput();
        input->message_async.data = input;
        uv_async_init(uv_default_loop(), &input->message_async, NodeMidiInput::EmitMessage);
        uv_unref((uv_handle_t*)uv_default_loop());
        input->Wrap(args.This());
        return args.This();
    }

I couldn't quite figure out what: uv_unref((uv_handle_t*)uv_default_loop()); was there to do so I tried commenting it out, rebuilt and then:

amorton@pavlov:~/projects/node-midi% node test/input-test.js
1
MidiKeys
m:144,46,95 d:0
m:144,46,0 d:0.168570572
m:144,47,95 d:0.000112732
m:144,47,0 d:0.017246667

Which is to say it started working. Maybe the maintainers can weigh in why that was there?

@drewish
Collaborator

It seems like that line carried over when the code was upgraded from libev: b481aea#diff-33494fc3bfb02f47665c320bb90d43e6L254

The libev code originated here: adb62e3#diff-33494fc3bfb02f47665c320bb90d43e6R196

I can't find a corresponding ev_ref() or uv_ref() in either so it seems like the line might have been copy/pasted in from some other source?

I'm going to open up a PR to remove this line.

@drewish drewish added a commit to drewish/node-midi that referenced this issue Dec 14, 2013
@drewish drewish Remove unmatched uv_unref() causing segfault 7d74968
@drewish drewish added a commit to drewish/node-midi that referenced this issue Dec 14, 2013
@drewish drewish Remove unmatched uv_unref() causing segfault
Also, properly close the async watcher when closing the port.

Fixes justinlatimer#16
994f5bd
@drewish
Collaborator

Any of the folks that ran into this interested in testing my PR?

@uberscientist

I was going to post a comment the other day saying "Thank you!", I hadn't tried your patch until you asked though :)

It works! No more segfault, and I'm able to read midi. We ended up writing directly to the /dev/ file descriptors for node knockout 🎹 https://www.youtube.com/watch?v=aAxqTc427V0

I hope the author responds ❤️

@drewish
Collaborator
@granmoe

Hi. I applied the fix referenced above, but I'm still getting a segfault. Here is the stack printed using segfault_handler:

PID 4776 received SIGSEGV for address: 0x11

/home/matt/Programming/NodeProjects/MIDI/midiserver/node_modules/segfault-handler/build/Release/segfault_handler.node(+0xf1e)[0x7f06de4ccf1e]

/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f06dea9ecb0]

node(uv_unref+0x1d)[0x95db7d]

/home/matt/Programming/NodeProjects/MIDI/midiserver/node_modules/midi/build/Release/midi.node(_ZN13NodeMidiInput3NewERKN2v89ArgumentsE+0x2a4)[0x7f06de2c72c4]

node[0x5c490d]
[0x263340d06362]

Can anyone point me in the right direction regarding how to find this bug? I am currently learning how to use objdump and readelf to explore this.

@drewish
Collaborator
@drewish
Collaborator

@granmoe, I'm having problems getting the alsa kernel modules installing on my linode server... I'll have to try getting local installation up and running.

@uberscientist

@granmoe, Have any other information about the environment you're building and running node-midi with? (node version, linux distro, etc)

You might be referencing a different version of node-midi than the rebuilt one. I did something like require('./midi.js'); to make sure I had the right version loaded.

I am on arch linux, x86_64, node v0.10.24

@granmoe

This occurred on a Ubuntu 12.04 LTS with node version 0.10.24. Here is the output of npmlist:

application-name@0.0.1 /home/matt/Programming/NodeProjects/MIDI/midiserver
├── commander@2.1.0
├─┬ midi@0.7.0
│ └── bindings@1.1.1
├─┬ segfault-handler@0.2.1
│ └── bindings@1.1.1
└── websocket@1.0.8

@drewish
Collaborator

@granmoe what's the JS code you're running look like?

You can try building a debug version of module (you might need to install the node-gyp module):

node-gyp -d clean configure build

Then you can run it using gdb:

gdb --args /usr/bin/node test/virtual-loopback-test-automated.js

It'll load the program and you'll end up with a (gdb) prompt:

GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/nodejs...(no debugging symbols found)...done.
(gdb) 

Then you can type run to start it:

(gdb) run
Starting program: /usr/bin/nodejs test/virtual-loopback-test-automated.js
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7ff7700 (LWP 2591)]
[New Thread 0x7fffefde5700 (LWP 2592)]
Enumerating inputs
Input found: Midi Through:0
Input found: RtMidi Output Client:0
Enumerating outputs
Output found: Midi Through:0
Output found: RtMidi Output Client:0
Sending message
Sending message
Sending message
Sending message
Sending message
Sending message
Sending message
Sending message
Sending message
nodejs: ../src/node_object_wrap.h:104: virtual void node::ObjectWrap::Unref(): Assertion `!handle_.IsWeak()' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6c01037 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) 

So here you see what happens with ALSA on Linux where the portName() doesn't match what the test is looking for and we end up calling close() on an un-opened port, demonstrating the bug reported in #21.

Now you can ask for a backtrace to see exactly how (from a C++ perspective) we got to this crash:

(gdb) backtrace
#0  0x00007ffff6c01037 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6c04698 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6bf9e03 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff6bf9eb2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x000000000081b772 in node::ObjectWrap::Unref() ()
#5  0x00007ffff69bcd63 in NodeMidiInput::ClosePort (args=...) at ../src/node-midi.cpp:300
#6  0x00000000005ca6e3 in ?? ()
#7  0x00003f6274406362 in ?? ()
...

Go ahead and give this a try and we'll be able to see if you're run into a new issue or a known one.

@granmoe

Thank you for your responses, @drewish =) I am running this project: https://github.com/PauloSeb/midiServer (the midiServer.js file), and it blows up at the midi.input() call. Here is the output from the steps you gave above:

matt@matt-Inspiron-N5040:~/Programming/NodeProjects/MIDI/midiserver/node_modules/midi$ gdb --args /usr/bin/node test/virtual-loopback-test-automated.js
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
http://bugs.launchpad.net/gdb-linaro/...
Reading symbols from /usr/bin/node...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/node test/virtual-loopback-test-automated.js
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7ff7700 (LWP 6439)]

Program received signal SIGSEGV, Segmentation fault.
0x000000000095db7d in uv_unref ()
(gdb) backtrace
#0 0x000000000095db7d in uv_unref ()
#1 0x00007ffff69da2c4 in NodeMidiInput::New(v8::Arguments const&) ()
from /home/matt/Programming/NodeProjects/MIDI/midiserver/node_modules/midi/build/Release/midi.node
#2 0x00000000005c490d in ?? ()
#3 0x0000122a53c06362 in ?? ()
#4 0x00003b261fb2f6f1 in ?? ()
#5 0x0000122a53c062c1 in ?? ()
#6 0x00007fffffffdaf0 in ?? ()
#7 0x00007fffffffdb50 in ?? ()
#8 0x0000122a53c0d3f3 in ?? ()
#9 0x00000ee2edb08051 in ?? ()
#10 0x000015115df52389 in ?? ()
#11 0x000015115df52389 in ?? ()
#12 0x0000000000000000 in ?? ()

@drewish
Collaborator

@granmoe yeah it looks like you're running the un-patched code. Try replacing node-midi.cpp with this patched copy from my repo.

@justinlatimer justinlatimer closed this in #32 Jan 21, 2014
@granmoe

Thanks, @drewish. That fixed the problem!

@justinlatimer

This is fixed in midi v0.7.1 - just pushed to npm!

@drewish
Collaborator

@granmoe awesome!

@justinlatimer exciting! thanks for getting that out there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment