Occasionally crashes when trying to save Instrument or Master

[polluxsynth]

(Built from master a week ago or so, Zyn-Fuson presenting itself as v3.0.6, running on Debian Buster using the self contained application).

Occasionally when saving Instrument or Master, the whole kit'n'kaboodle crashes when pressing Enter after entering the filename to save to.

The following is printed on stdout/stderr, which is likely not very helpful. If there's any debug flag I can turn on that can print more informative messages I'd be happy to do that.

can't convert nil to Integer (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue

I have not been able to determine a pattern as to when this happens, more than it seems to happen after I've been working on a sound that I'm really happy with, so perhaps excessive UI tweaking and/or playing time comes into the picture

[fundamental]

So, a while back some work was put in to make sure that backtraces were printed as completely as they could be. Looks like this might be one of the remaining failure cases.

[fundamental]

Well, I ran some tests against mruby with both our commit id and their git HEAD. I can see some minor changes in the backtrce dumping, but with either version it looks like there's no backtrace. The backtrace fixes that I put in place should still be working just fine. I could see something weird perhaps happening with it on windows where the old 'superhack' is in place to reroute stderr destined information, but on Linux there's only one scenario I can think of where no backtrace exists for an error:

The error happens purely from a chained set of calls through C and no ruby code is directly run through the VM. Are you able to run gdb with the GUI?

You should be able to set a breakpoint for mrb_raise() and mrb_raisef()

Eventually it will boil over to the code which is currently failing to provide a backtrace https://github.com/mruby/mruby/blob/master/src/error.c#L131 https://github.com/mruby/mruby/blob/master/src/print.c#L53 https://github.com/mruby/mruby/blob/master/src/backtrace.c#L100 etc (note the function names, not the line numbers). I expect the raise call to come from one of the error points in object.c, but what triggers the invalid cast from nil is where the bug lies.

[polluxsynth]

I haven't tried running the GUI with gdb yet, I assume that I'd have to start zynaddsubfx first, and then zyn-fusion in gdb? Are there any instructions on how to run them separately?

EDIT: After some experimentation and looking at the output from ps aux, this seems to work:

$ zynaddsubfx --no-gui -P 12345 &
$ gdb zyn-fusion
(gdb) set args osc.udp://tabby.pollux.se:12345 --builtin --no-hotload
(gdb) run

Gdb claims there are no debugging symbols; is there a quick way to enable them in a build?

[fundamental]

Gdb claims there are no debugging symbols; is there a quick way to enable them in a build?

Strange. I had thought that they would be in there and I've intentionally avoided stripping any symbols out. I think that the mruby part of the build respects CFLAGS, but if not build_config.rb:129 in the mruby-zest-build repo shows another way that compiler flags can be injected (-g or -ggdb in this case).

[polluxsynth]

Turns out that there are at least some debugging symbols present, zyn-fusion segfaulted at one point and it happily told me where, I could extract some variables etc. Don't think it's related but I'll post part of the debugging session here anyway. (I've since reinstated the printf on line 887; occasionally I see the printout but it hasn't crashed since). So it could be that there are some files without debugging symbols but not all.

Thread 1 "zyn-fusion" received signal SIGSEGV, Segmentation fault.
__memmove_sse2_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:497

(gdb) frame 1
#1  0x00007ffff72f1007 in br_tick (br=0x555555add4b0) at src/bridge.c:888
888	            memmove(base, base+N, sizeof(void*)*(M-N));
(gdb) l
883	        } else {
884	            char **base = br->rlimit;
885	            int N = br->frame_messages;
886	            int M = br->rlimit_len;
887	            //printf("[INFO] Shrinking rate limit queue %d=>%d\n", M, M-N);
888	            memmove(base, base+N, sizeof(void*)*(M-N));
889	            br->rlimit_len = M-N;
890	        }
891	        //wait 10ms
892	        //usleep(10000);
(gdb) p br->rlimit
$4 = (char **) 0x5555565ef630
(gdb) p base
$5 = <optimized out>
(gdb) p br->frame_messages
$6 = 128
(gdb) p br->rlimit_len
$7 = 126

EDIT: Looking at the preceding code, this looks like a race, if I understand the code, br->frame_messages is bumped by calling do_send(), so it should never be larger than br->rlimit_len, so if it is, something else must have been calling do_send() in the meantime. I haven't studied the rest of the code so this might be totally bogus.

EDIT: Since this looks like something different from what issue is concerned about I'll open a separate issue for it.

[polluxsynth]

At an arbitrary time during a session I attempted to Load Master, and upon clicking on the Enter widget, the mrb_raisef() bp was hit:

Thread 1 "zyn-fusion" hit Breakpoint 2, mrb_raisef (
    mrb=mrb@entry=0x555555872760, c=0x5555559fd4b0, 
    fmt=fmt@entry=0x7ffff73ca606 "can't convert %Y to Integer")
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/error.c:400
400	{
(gdb) bt
#0  mrb_raisef (mrb=mrb@entry=0x555555872760, c=0x5555559fd4b0, 
    fmt=fmt@entry=0x7ffff73ca606 "can't convert %Y to Integer")
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/error.c:400
#1  0x00007ffff729b395 in mrb_to_int (mrb=mrb@entry=0x555555872760, val=...)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/object.c:518
#2  0x00007ffff72b4d84 in mrb_get_args (mrb=mrb@entry=0x555555872760, 
    format=0x7ffff73cca59 "*!", format@entry=0x7ffff73cca58 "i*!")
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/class.c:1151
#3  0x00007ffff72c3f70 in aget_index (mrb=0x555555872760, index=...)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/array.c:838
#4  aget_index (mrb=0x555555872760, index=...)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/array.c:824
#5  mrb_ary_aget (mrb=0x555555872760, self=...)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/array.c:892
#6  0x00007ffff72a9c00 in mrb_vm_exec (mrb=mrb@entry=0x555555872760, 
    proc=<optimized out>, proc@entry=0x555555a71510, 
    pc=0x7ffff73483ac <gem_mrblib_mruby_widget_lib_proc_iseq_38116+44> "\001\003\005\024\005/\005\005")
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/vm.c:1471
#7  0x00007ffff72ac68d in mrb_vm_run (mrb=mrb@entry=0x555555872760, 
    proc=0x555555a71510, self=..., stack_keep=<optimized out>)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/vm.c:992
#8  0x00007ffff72acd5c in mrb_run (self=..., proc=0x555555a71510, 
    mrb=0x555555872760)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/vm.c:2874
#9  mrb_funcall_with_block (mrb=0x555555872760, self=..., mid=824, 
    argc=<optimized out>, argv=0x7fffffffd650, blk=...)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/vm.c:491
#10 0x00007ffff72acef0 in mrb_funcall_with_block (
    mrb=mrb@entry=0x555555872760, self=..., mid=824, argc=argc@entry=2, 
    argv=argv@entry=0x7fffffffd650, blk=...)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/vm.c:411
#11 0x00007ffff72acfa2 in mrb_funcall_argv (mrb=mrb@entry=0x555555872760, 
    self=..., mid=<optimized out>, argc=argc@entry=2, 
    argv=argv@entry=0x7fffffffd650)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/include/mruby/value.h:336
#12 0x00007ffff72ad23c in mrb_funcall (mrb=0x555555872760, self=..., 
    name=name@entry=0x7ffff7307666 "key", argc=argc@entry=2)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/vm.c:352
#13 0x00007ffff724fa56 in zest_key (z=0x555555872740, 
    key=0x7fffffffd928 "\r", press=<optimized out>)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/src/mruby-widget-lib/src/api.c:296
#14 0x0000555555556a82 in onUtf8KeyEvent ()
#15 0x0000555555556bb4 in onEvent ()
#16 0x0000555555558cd2 in puglDispatchEvent ()
#17 0x000055555555c4b2 in puglProcessEvents ()
#18 0x000055555555804d in main ()
(gdb) frame 1
#1  0x00007ffff729b395 in mrb_to_int (mrb=mrb@entry=0x555555872760, val=...)
    at /home/ricard/src/zyn-fusion-build/src/mruby-zest-build/mruby/src/object.c:518
518	    mrb_raisef(mrb, E_TYPE_ERROR, "can't convert %Y to Integer", val);
(gdb) p val
$2 = {value = {f = 0, p = 0x0, i = 0, sym = 0}, tt = MRB_TT_FALSE}

[fundamental]

I think this issue is likely resolved, but if not the MRuby submodule update should mean that proper backtraces (without gdb) will be generated.

[polluxsynth]

Thanks. I've built binaries from the latest git and will test more later tonight.

[polluxsynth]

Didn't do as much saving and loading as I'd planned to (I started playing for too long on one of the sounds I'd made...) but for what it's worth it hasn't crashed so far while saving/loading instruments/master.

[zynmuse]

I suspect the Mruby compiler bug Mark found/solved yesterday in issue #287 will also solve this problem.

[polluxsynth]

Thanks @synmuse, I'll rebuild with the latest master for further testing.

[polluxsynth]

Seems to be solved, I've been running Zyn quite a bit lately and have not had it crash on load/save instrument/master once since the mruby compiler fix was brought in.

[fundamental]

Excellent :)

[polluxsynth]

In fact, the whole of Zyn seems to be be rock stable since this change. Before it was having random crashes and glitches which I never reported because I couldn't find a way to consistently trigger them, such as the polyType occasionally being set to Latched when loading an instrument, or the Apply button just displaying the spinning graphic without actually performing the apply function, or the whole thing just crashing at arbitrary intervals.