Guitarix segfault when moving a control that is outputting midi feedback

[Rippert]

So I've got the Issue #8 commit compiling and running on my RPi. To test the midi feedback I assign a continuous controller to one of the knobs. I've tried Drive and Main Volume, and they both act the same.

After moving the control with the mouse and seeing the CC output on a midi monitor, the control freezes, the midi monitor gets flooded with repeating output at the last CC value, and then Guitarix segfaults.

Here's the full backtrace from gdb:

Reading symbols from guitarix...
(gdb) run
Starting program: /usr/bin/guitarix 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x71c23270 (LWP 9031)]
[New Thread 0x710f2270 (LWP 9032)]
[New Thread 0x708f1270 (LWP 9033)]
mlock 1267032 bytes
[New Thread 0x6b9c8270 (LWP 9034)]
[New Thread 0x6b815270 (LWP 9035)]
[New Thread 0x6b782270 (LWP 9036)]
[New Thread 0x665ff270 (LWP 9037)]
[New Thread 0x66785270 (LWP 9038)]
[New Thread 0x65dfe270 (LWP 9039)]
[New Thread 0x65aff270 (LWP 9040)]
[New Thread 0x650ff270 (LWP 9041)]

Thread 1 "guitarix" received signal SIGSEGV, Segmentation fault.
0x76cff344 in g_slice_alloc () from /usr/lib/libglib-2.0.so.0
(gdb) bt -full
#0  0x76cff344 in g_slice_alloc () at /usr/lib/libglib-2.0.so.0
#1  0x76cd94d4 in g_list_prepend () at /usr/lib/libglib-2.0.so.0
#2  0x7661f08c in  () at /usr/lib/libgtk-3.so.0
(gdb) 

That doesn't look too helpful, so I tried the trick where I run an instance with the -N switch, and one with the -G switch. This time it was the -N instance that was segfaulting. Here's its backtrace:

(gdb) run
Starting program: /usr/bin/guitarix -N
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x71c23270 (LWP 9143)]
[New Thread 0x7121a270 (LWP 9144)]
[New Thread 0x70a19270 (LWP 9145)]
mlock 1267032 bytes
[New Thread 0x6bd35270 (LWP 9146)]
[New Thread 0x6bb82270 (LWP 9147)]
[New Thread 0x66b73270 (LWP 9148)]
[New Thread 0x668ff270 (LWP 9149)]
[New Thread 0x66af0270 (LWP 9150)]
[New Thread 0x660fe270 (LWP 9151)]
Ctrl-C to quit
[New Thread 0x6607d270 (LWP 9152)]

Thread 1 "guitarix" received signal SIGSEGV, Segmentation fault.
0x005f0ec8 in sigc::slot_base::empty (this=0x10b1550)
    at /usr/include/sigc++-2.0/sigc++/functors/slot_base.h:329
329     { return (!rep_ || !rep_->call_); }
(gdb) bt -full
#0  0x005f0ec8 in sigc::slot_base::empty() const (this=0x10b1550)
    at /usr/include/sigc++-2.0/sigc++/functors/slot_base.h:329
        slot = @0x10b1550: {<sigc::functor_base> = {<No data fields>}, rep_ = 0x3, blocked_ = 25}
        __for_range = <synthetic pointer>: <optimized out>
#1  sigc::internal::signal_emit1<void, float, sigc::nil>::emit(sigc::internal::signal_impl*, float const&) (_A_a1=@0xed64e0: 0.377952754, impl=0x10b1540) at /usr/include/sigc++-2.0/sigc++/signal.h:1039
        slot = @0x10b1550: {<sigc::functor_base> = {<No data fields>}, rep_ = 0x3, blocked_ = 25}
        __for_range = <synthetic pointer>: <optimized out>
#2  sigc::signal1<void, float, sigc::nil>::emit(float const&) const
    (this=<optimized out>, _A_a1=@0xed64e0: 0.377952754) at /usr/include/sigc++-2.0/sigc++/signal.h:2951
#3  sigc::signal1<void, float, sigc::nil>::operator()(float const&) const
    (_A_a1=@0xed64e0: 0.377952754, this=<optimized out>) at /usr/include/sigc++-2.0/sigc++/signal.h:2967
#4  gx_engine::ParameterV<float>::trigger_changed() (this=<optimized out>)
    at ../src/gx_head/engine/gx_paramtable.cpp:1276
#5  0x005f1860 in gx_engine::MidiController::trigger_changed() (this=0xf9ae58)
    at ../src/headers/gx_parameter.h:726
        i = {param = 0xcddc40, _lower = 0, _upper = 1, toggle = false, _toggle_behaviour = 0}
        ctr_list = 
            std::__cxx11::list = {[0] = {param = 0xcddc40, _lower = 0, _upper = 1, toggle = false, _toggle_behaviour = 0}}
        n = 12887632
        saved_values = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 46, 0 <repeats 317 times>}
#6  gx_engine::MidiControllerList::on_val_chg() (this=0x7ef93df0)
--Type <RET> for more, q to quit, c to continue without paging--c
    at ../src/gx_head/engine/gx_paramtable.cpp:585
        i = {param = 0xcddc40, _lower = 0, _upper = 1, toggle = false, _toggle_behaviour = 0}
        ctr_list = std::__cxx11::list = {[0] = {param = 0xcddc40, _lower = 0, _upper = 1, toggle = false, _toggle_behaviour = 0}}
        n = 12887632
        saved_values = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 46, 0 <repeats 317 times>}
#7  0x7598fff8 in Glib::DispatchNotifier::pipe_io_handler(Glib::IOCondition) () at /usr/lib/libglibmm-2.4.so.1
#8  0x759925a4 in Glib::IOSource::dispatch(sigc::slot_base*) () at /usr/lib/libglibmm-2.4.so.1
#9  0x759927f4 in Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () at /usr/lib/libglibmm-2.4.so.1
#10 0x76cdeb8c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#11 0x00000000 in  ()
(gdb) 

[brummer10]

Same as with issue #8 I cant reproduce this here. But, I found a trigger point to much which I've removed now. Still, didn't know if that fix this issue. Do the segfault happen only when midi feedback is enabled, or as well without feedback?

[Rippert]

Only happens with midi feedback enabled, as far as I can tell. Guess the Pi is a picky critter. I'll try your new commit first thing tomorrow. Thanks.

[Rippert]

I tried your latest commit,

Midi CC Only trigger value changed signal when the value realy changed

and it was segfaulting after moving a midi linked control still, but it seemed to take longer to actually crash.

I tried reverting to

Try to fix issue #9

and now it doesn't segfault, but the control goes into some sort of loop where it is oscillating between its original value and the new value. Here's some midi feedback output while it's stuck in this mode:

channel  1   control-change    10   0
channel  1   control-change    10   5
channel  1   control-change    10   3
channel  1   control-change    10   7
channel  1   control-change    10  15
channel  1   control-change    10  14
channel  1   control-change    10  13
channel  1   control-change    10   8
channel  1   control-change    10  12
channel  1   control-change    10   9
channel  1   control-change    10   4
channel  1   control-change    10   6
channel  1   control-change    10   0
channel  1   control-change    10   1
channel  1   control-change    10  18
channel  1   control-change    10  23
channel  1   control-change    10   2
channel  1   control-change    10   0
channel  1   control-change    10   5
channel  1   control-change    10   3
channel  1   control-change    10   7
channel  1   control-change    10  15
channel  1   control-change    10  14
channel  1   control-change    10  13
channel  1   control-change    10   8
channel  1   control-change    10  12
channel  1   control-change    10   9
channel  1   control-change    10   4
channel  1   control-change    10   6
channel  1   control-change    10   0
channel  1   control-change    10   1
channel  1   control-change    10  18
channel  1   control-change    10  23
channel  1   control-change    10   2
channel  1   control-change    10   0
channel  1   control-change    10   5
channel  1   control-change    10   3
channel  1   control-change    10   7
channel  1   control-change    10  15
channel  1   control-change    10  14
channel  1   control-change    10  13
channel  1   control-change    10   8
channel  1   control-change    10  12
channel  1   control-change    10   9
channel  1   control-change    10   4
channel  1   control-change    10   6
channel  1   control-change    10   0
channel  1   control-change    10   1
channel  1   control-change    10  18
channel  1   control-change    10  23
channel  1   control-change    10   2
channel  1   control-change    10   0
channel  1   control-change    10   5
channel  1   control-change    10   3
channel  1   control-change    10   7
channel  1   control-change    10  15
channel  1   control-change    10  14
channel  1   control-change    10  13
channel  1   control-change    10   8
channel  1   control-change    10  12
channel  1   control-change    10   9
channel  1   control-change    10   4
channel  1   control-change    10   6
channel  1   control-change    10   0
channel  1   control-change    10   1
channel  1   control-change    10  18
channel  1   control-change    10  23
channel  1   control-change    10   2
channel  1   control-change    10   0
channel  1   control-change    10   5
channel  1   control-change    10   3
channel  1   control-change    10   7
channel  1   control-change    10  15
channel  1   control-change    10  14
channel  1   control-change    10  13
channel  1   control-change    10   8
channel  1   control-change    10  12
channel  1   control-change    10   9
channel  1   control-change    10   4
channel  1   control-change    10   6
channel  1   control-change    10   0
channel  1   control-change    10   1
channel  1   control-change    10  18
channel  1   control-change    10  23
channel  1   control-change    10   2
channel  1   control-change    10   0
channel  1   control-change    10   5
channel  1   control-change    10   3
channel  1   control-change    10   7
channel  1   control-change    10  15
channel  1   control-change    10  14
channel  1   control-change    10  13
channel  1   control-change    10   8
channel  1   control-change    10  12
channel  1   control-change    10   9
channel  1   control-change    10   4
channel  1   control-change    10   6

This goes on until I exit guitarix, but guitarix doesn't crash.

[Rippert]

I just tried disconnecting the input midi to guitarix, and leaving the output connected. Now it works properly without crashing. Looks like some weird midi loop. I'll try to track that down and then test again.

[Rippert]

Yes, totally my fault. I got mixed up with the jack system_capture_midi names and the alsa midi-through names. I'm doing a clean recompile now, and I will let you know which commits work properly. I'm guessing there was no bug in your code at all. Sorry about probably wasting your time.

[Rippert]

OK, tried the last three commits, and they all work without crashing. The latest one does seem to have less repeated values. Sorry about this.

[brummer10]

Thank you @Rippert, your report help to make the code more stable and responsible. Even if it doesn't was a 'bug', it could be done better.