Skip to content
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

Zyn fusion display crash 3 times. second time with core dump! #287

Closed
zynmuse opened this issue Jul 4, 2021 · 26 comments
Closed

Zyn fusion display crash 3 times. second time with core dump! #287

zynmuse opened this issue Jul 4, 2021 · 26 comments
Labels

Comments

@zynmuse
Copy link

zynmuse commented Jul 4, 2021

I'm running the latest available software of zynaddsubfx/zynfusion 3.0.6-rc3.
I have built both synth and ui with debugging and I run zynaddsubfx and zynfusion as two processes both under gdb so I can grab any crash data.
ZynFusion (UI) has crashed a few times but doesn't usually give any useful stack trace. However today I am using the system and zynFusion is crashing quite frequently. One of those crashes has provided a back trace so I am adding below the gdb output of a sequence of three crashes. The middle one did give some back trace data.
I hope this may be useful.

==================================Zyn-Fusion CRASHES
================================CRASH 1 Zynaddsubfx carries on OK, just need to restart zyn-fusion

27.0.0.1:1234
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[INFO:Zyn] setup_pugl()
[INFO:Zyn] zest_tick()
[INFO:Zyn] zest_open()
[INFO:Zyn] running in dev mode
[INFO:Zyn] Starting Zyn-Fusion
[INFO:Zyn] Thanks for supporting the development of this project
[INFO:Zyn] Creating MRuby Interpreter...
[debug] parsing json file
[debug] json parsed succesfully
Time for a fast load is 1.307ms load(0.004) class(0.001) spawn(1.302)...
making reverse graph[1099]<0.914 ms>
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpEnvelope/Prepeating"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpLfo/Pcutoff"...
non float value (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue
[Inferior 1 (process 9927) exited with code 01]
No stack.
(gdb)

======================RESTART zynFusion after first crash================================
======================runs for a while then crashes again - this time give a stack trace===

(gdb) r
Starting program: /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/zest osc.udp://127.0.0.1:1234
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[INFO:Zyn] setup_pugl()
[INFO:Zyn] zest_tick()
[INFO:Zyn] zest_open()
[INFO:Zyn] running in dev mode
[INFO:Zyn] Starting Zyn-Fusion
[INFO:Zyn] Thanks for supporting the development of this project
[INFO:Zyn] Creating MRuby Interpreter...
[debug] parsing json file
[debug] json parsed succesfully
Time for a fast load is 1.306ms load(0.005) class(0.001) spawn(1.3)...
making reverse graph[1099]<0.887 ms>
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpEnvelope/Prepeating"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpLfo/Pcutoff"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FreqLfo/Pcutoff"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FilterEnvelope/Prepeating"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FilterLfo/Pcutoff"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpEnvelope/Prepeating"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpLfo/Pcutoff"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FreqLfo/Pcutoff"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FilterEnvelope/Prepeating"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FilterLfo/Pcutoff"...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff785a95e in mrb_realloc_simple (mrb=0x55500302545b, p=0x0, len=64)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/gc.c:227
227 p2 = (mrb->allocf)(mrb, p, len, mrb->allocf_ud);
(gdb) bt
#0 0x00007ffff785a95e in mrb_realloc_simple (mrb=0x55500302545b, p=0x0, len=64)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/gc.c:227
#1 0x00007ffff785a9c1 in mrb_realloc (mrb=mrb@entry=0x55500302545b, p=p@entry=0x0, len=len@entry=64)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/gc.c:241
#2 0x00007ffff785a9fa in mrb_malloc (mrb=mrb@entry=0x55500302545b, len=len@entry=64)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/gc.c:257
#3 0x00007ffff786949e in ary_expand_capa (mrb=mrb@entry=0x55500302545b, a=a@entry=0x5555559ba040, len=len@entry=2)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/array.c:215
#4 0x00007ffff786ad47 in mrb_ary_push (mrb=0x55500302545b, ary=..., elem=...)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/array.c:502
#5 0x00007ffff78b459a in remote_cb_fvec (cb=0x555555e9bcb0, msg=)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/src/mruby-widget-lib/src/gem.c:763
#6 remote_cb (msg=, data=0x555555e9bcb0)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/src/mruby-widget-lib/src/gem.c:824
#7 0x00007ffff7913e11 in run_callbacks (br=br@entry=0x5555559abfc0, line=line@entry=0x5555569e8890)
at src/bridge.c:598
#8 0x00007ffff79140e0 in cache_set_vector (br=br@entry=0x5555559abfc0,
uri=uri@entry=0x555556b682c0 "/part2/kit0/adpars/GlobalPar/FilterEnvelope/out",
types=types@entry=0x555555df1ed0 "ff", args=, args@entry=0x555555dac320) at src/bridge.c:179
#9 0x00007ffff7915c3c in br_recv (msg=0x555556b682c0 "/part2/kit0/adpars/GlobalPar/FilterEnvelope/out",
br=0x5555559abfc0) at src/bridge.c:838
#10 br_recv (br=0x5555559abfc0, msg=) at src/bridge.c:804
#11 0x00007ffff7915dcf in on_read (req=0x5555559abfc8, nread=, buf=0x7fffffffa100,
addr=, flags=) at src/bridge.c:276
#12 0x00007ffff774ee0f in ?? () from /usr/lib/libuv.so.1
#13 0x00007ffff7750be6 in uv.io_poll () from /usr/lib/libuv.so.1
#14 0x00007ffff773f587 in uv_run () from /usr/lib/libuv.so.1
#15 0x00007ffff7916176 in br_tick (br=0x5555559abfc0) at src/bridge.c:862
#16 0x00007ffff78b3612 in mrb_remote_tick (mrb=, self=...)
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/src/mruby-widget-lib/src/gem.c:471
#17 0x00007ffff7872519 in mrb_vm_exec (mrb=mrb@entry=0x555555987960, proc=,
proc@entry=0x555555a0c4c0, pc=0x7ffff7951b8b <gem_mrblib_mruby_widget_lib_proc_iseq_75313+11> "\027\003")
--Type for more, q to quit, c to continue without paging--c
at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/vm.c:1471
#18 0x00007ffff7875291 in mrb_vm_run (mrb=mrb@entry=0x555555987960, proc=, self=..., stack_keep=) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/vm.c:992
#19 0x00007ffff7875934 in mrb_run (self=..., proc=0x555555a0c4c0, mrb=0x555555987960) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/vm.c:2874
#20 mrb_funcall_with_block (mrb=0x555555987960, self=..., mid=6726, argc=, argv=0x7fffffffdc00, blk=...) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/vm.c:491
#21 0x00007ffff7875ad3 in mrb_funcall_with_block (mrb=mrb@entry=0x555555987960, self=..., mid=6726, argc=argc@entry=0, argv=0x7fffffffdc00, blk=...) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/vm.c:411
#22 0x00007ffff7875b6f in mrb_funcall_argv (mrb=mrb@entry=0x555555987960, self=..., mid=, argc=argc@entry=0, argv=) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/vm.c:502
#23 0x00007ffff7875c85 in mrb_funcall (mrb=0x555555987960, self=..., name=name@entry=0x7ffff79267e4 "tick_remote", argc=argc@entry=0) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/mruby/src/vm.c:352
#24 0x00007ffff78b0d39 in zest_tick (z=0x555555987940) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/src/mruby-widget-lib/src/api.c:350
#25 0x00005555555582d6 in main ()
(gdb)
========================================Restart for third time === runs for a while then crashes again with no backtrace===========
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/zyn-fusion-build/mruby-zest-build/zest osc.udp://127.0.0.1:1234
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[INFO:Zyn] setup_pugl()
[INFO:Zyn] zest_tick()
[INFO:Zyn] zest_open()
[INFO:Zyn] running in dev mode
[INFO:Zyn] Starting Zyn-Fusion
[INFO:Zyn] Thanks for supporting the development of this project
[INFO:Zyn] Creating MRuby Interpreter...
[debug] parsing json file
[debug] json parsed succesfully
Time for a fast load is 1.805ms load(0.005) class(0.001) spawn(1.799)...
making reverse graph[1099]<0.858 ms>
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpEnvelope/Prepeating"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/AmpLfo/Pcutoff"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FreqLfo/Pcutoff"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FilterEnvelope/Prepeating"...
[WARNING:osc-bridge] Invalid Handle "/part2/kit0/adpars/GlobalPar/FilterLfo/Pcutoff"...
non float value (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue
[Inferior 1 (process 10424) exited with code 01]
(gdb)

============================================================================================

@zynmuse
Copy link
Author

zynmuse commented Jul 4, 2021

I ran this under valgrind and it lasted for much longer before it exited again.
The valgring.txt file didn't find any memory allocation problems.

@fundamental
Copy link
Member

Thanks for the crash report. I'm not sure about the 2nd crash with a memory error, but the first and last one look like normal MRuby level exceptions caused by a programming bug in one of the widgets. As such it should be pretty deterministic. Can you provide steps for replication? Normally the TypeError should have a full backtrace, but it looks like that's not happening in this case. It can still be traced down if steps to trigger the bug are available.

@fundamental fundamental added the bug label Jul 4, 2021
@zynmuse
Copy link
Author

zynmuse commented Jul 5, 2021

I ran this under valgrind and it lasted for much longer before it exited again.
The valgring.txt file didn't find any memory allocation problems.

@fundamental
Copy link
Member

Rephrasing - The two crashes resulting in:

non float value (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue

Are ones which should have a deterministic way of getting them to happen. If you can provide steps to replicate that crash reliably it can very likely be fixed by modifying one of the mruby-zest-build/src/mruby-zest//.qml files. So, when you have a step by step method to trigger that specific crash, just update this issue with the steps.

@zynmuse
Copy link
Author

zynmuse commented Jul 5, 2021

Can't say exactly what was happening.
I was sending a series of rapid notes (midi over osc) to zyn part 2 (counting from 0).
I was adjusting various parameters in the zynfusion oscillator screen.
I'll try to gather more info if/when it happens again.

Is the "Invalid Handle" message important? I see this a lot!

@fundamental
Copy link
Member

Is the "Invalid Handle" message important? I see this a lot!

Mildly important, but invalid handle messages should not result in a crash. It implies the osc schema (mruby-zest-build/src/osc-bridge//.json ) is out of sync in some way. It happens from time to time as PRs get merged.

@zynmuse
Copy link
Author

zynmuse commented Sep 7, 2021

This problem is still present in the current master of 6 September..
Usually when a number of parts are in use and a fair number of osc control messages and midi notes being sent to zyn.
Usually when changing parameters in the Oscillator window, and the graph is being redrawn.
zest will crash with no stack trace.
This will happen every 5 - 10 minutes.

I can restart zest and carry on.

(gdb) r
Starting program: /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/build/zyn-fusion-linux-64bit-3.0.6-git-release/zyn-fusion osc.udp://127.0.0.1:1234
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[INFO:Zyn] setup_pugl()
[INFO:Zyn] zest_tick()
[INFO:Zyn] zest_open()
[INFO:Zyn] Found Assets at ./
[INFO:Zyn] Starting Zyn-Fusion
[INFO:Zyn] Thanks for supporting the development of this project
[INFO:Zyn] Creating MRuby Interpreter...
[debug] parsing json file
[debug] json parsed succesfully
Time for a fast load is 1.617ms load(0.004) class(0.0) spawn(1.613)...
making reverse graph[1103]<1.498 ms>
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
non float value (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue
[Inferior 1 (process 10348) exited with code 01]
(gdb) bt
No stack.

@zynmuse
Copy link
Author

zynmuse commented Sep 7, 2021

Could I put a break point somewhere to get some useful stack information?

@fundamental
Copy link
Member

The error getting raised is either numeric.c:1252 or numeric.c:43 within mruby's source. If it's a problem in C code injecting a non-float value then it might give a helpful backtrace. If it's ruby side then it's possible that it won't really provide anything helpful, but in that case it really out to provide a backtrace... Not sure why there's no backtrace information there as all fatal errors should try to get mruby to print out a backtrace.

@fundamental
Copy link
Member

Also, if it isn't mruby's fault it might be useful to let valgrind run for a while. If you're sending a lot of OSC messages then perhaps a malformed message is getting sent and mishandled leading to the later crash. If that can be shown to be what's happening then even if it's hard to replicate the problem could be fuzzed until some prerequisites are identified.

@zynmuse
Copy link
Author

zynmuse commented Sep 8, 2021

Thanks for that.
It's late here in UK!
Tomorrow I'll find time to put some breakpoints in.
Hopefully I can get a backtrace.

@zynmuse
Copy link
Author

zynmuse commented Sep 8, 2021

HERE'S A BACKTRACE FROM THIS POBLEM

Breakpoint 2, mrb_to_flo (mrb=mrb@entry=0x5555559b4270, val=...)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/numeric.c:43
43	    mrb_raise(mrb, E_TYPE_ERROR, "non float value");
(gdb) bt
#0  mrb_to_flo (mrb=mrb@entry=0x5555559b4270, val=...)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/numeric.c:43
#1  0x00007ffff7866113 in mrb_get_args (mrb=mrb@entry=0x5555559b4270, format=0x7ffff7929510 "", 
    format@entry=0x7ffff792950f "f")
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/class.c:1140
#2  0x00007ffff78f00c7 in math_log10 (mrb=0x5555559b4270, obj=...)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrbgems/mruby-math/src/math.c:553
#3  0x00007ffff7879519 in mrb_vm_exec (mrb=mrb@entry=0x5555559b4270, proc=<optimized out>, 
    proc@entry=0x555555a2e4a0, pc=0x7ffff79a11e1 <gem_mrblib_mruby_widget_lib_proc_iseq_28486+17> "A\003\071\003")
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/vm.c:1471
#4  0x00007ffff787c31e in mrb_vm_run (mrb=mrb@entry=0x5555559b4270, proc=<optimized out>, self=..., 
    stack_keep=<optimized out>)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/vm.c:992
#5  0x00007ffff787c9ab in mrb_run (self=..., proc=0x555555a2e4a0, mrb=0x5555559b4270)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/vm.c:2874
#6  mrb_funcall_with_block (mrb=0x5555559b4270, self=..., mid=1328, argc=<optimized out>, argv=0x7fffffffd800, 
    blk=...) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/vm.c:491
#7  0x00007ffff787cb62 in mrb_funcall_with_block (mrb=mrb@entry=0x5555559b4270, self=..., mid=1328, 
    argc=argc@entry=0, argv=0x7fffffffd800, blk=...)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/vm.c:411
#8  0x00007ffff787cbfb in mrb_funcall_argv (mrb=mrb@entry=0x5555559b4270, self=..., mid=<optimized out>, 
    argc=argc@entry=0, argv=<optimized out>)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/vm.c:502
#9  0x00007ffff787cd05 in mrb_funcall (mrb=0x5555559b4270, self=..., name=name@entry=0x7ffff792bf89 "draw", 
    argc=argc@entry=0)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/vm.c:352
#10 0x00007ffff78b9621 in zest_draw (z=0x5555557e3d50)
    at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/src/api.c:322
#11 0x0000555555556b11 in onDisplay ()
#12 0x0000555555556c65 in onEvent ()
#13 0x0000555555558fbe in puglDispatchEvent ()
#14 0x000055555555ce9a in puglProcessEvents ()
#15 0x000055555555838f in main ()
(gdb) 

@fundamental
Copy link
Member

Excellent. Thanks for the backtrace. There's only a few spots in the code which would trigger that (i.e. where log10()) is getting called. I think there's a chance that this is related to two bugs that I was able to replicate on my system. If not the MRuby git submodule update that I checked into the mruby-zest-build repo should mean that ruby backtraces are working again. So if the bug happens again (which I hope it doesn't), then the bug will be narrowed from roughly 5 possible locations in the codebase to exactly 1.

@zynmuse
Copy link
Author

zynmuse commented Sep 9, 2021

If I clone the master again now will I pick up your latest update?
If so I can repeat again. It happens only when I am interacting with the zyn-fusion interface.
I can probably make it happen again.

@fundamental
Copy link
Member

fundamental commented Sep 9, 2021 via email

@zynmuse
Copy link
Author

zynmuse commented Sep 9, 2021

OK
Please check back later today. I'm rebuilding now and will attempt to recreate the crash

@zynmuse
Copy link
Author

zynmuse commented Sep 9, 2021

I THINK THIS IS WHAT YOU NEED
[INFO:Zyn] Creating MRuby Interpreter...
[debug] parsing json file
[debug] json parsed succesfully
Time for a fast load is 2.208ms load(0.005) class(0.001) spawn(2.202)...
making reverse graph[1103]<1.024 ms>
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
trace (most recent call last):
[21] (unknown):0
[20] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:538:in draw
[19] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/time-profile.rb:24:in time
[18] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:539:in draw
[17] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:139:in render
[16] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrblib/range.rb:45:in each
[15] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:159:in render
[14] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/deps/mruby-nanovg/mrblib/context.rb:90:in draw
[13] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:160:in render
[12] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrblib/array.rb:17:in each
[11] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:162:in render
[10] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/deps/mruby-nanovg/mrblib/context.rb:116:in spork
[9] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:164:in render
[8] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:4048:in draw
[7] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:4048:in new
[6] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-zest/mrblib/util.rb:47:in initialize
[5] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-zest/mrblib/util.rb:130:in string_to_lines
[4] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-zest/mrblib/util.rb:73:in flush_word_buffer
[3] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrblib/range.rb:45:in each
[2] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-zest/mrblib/util.rb:74:in flush_word_buffer
[1] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-zest/mrblib/util.rb:82:in push_char
/JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-zest/mrblib/util.rb:82:in +: Float cannot be converted to String (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue
[Inferior 1 (process 14624) exited with code 01]
(gdb)

@zynmuse
Copy link
Author

zynmuse commented Sep 9, 2021

I now have another problem that is caused by the latest Master I have picked up today. Going back to the previous master this problem goes away.

recent .xmz files that I saved using /save_xmz are incompatible with the system. Older ones are OK!
Symptom - MIXER SCREEN CRASHES WHEN YOU TRY TO OPEN IT
Zynaddsubfx message is present:
Unknown addressBACKEND:online '/load_xmz:'

Stack trace is as above!

Maybe recently saved .xmz files contain something that was added on an earlier Master then removed again, causing an incompatibility?
Any ideas?

@fundamental
Copy link
Member

Excellent. Thanks for the backtrace. It looks like there's some sort of illegal character getting into a text display somewhere or at least that's the running theory. You should be able to print out what goes into the initialize call of EditRegion by going into src/mruby-zest/mrblib/util.rb:21 and adding the lines:

puts "string = #{string.inspect}"
puts "width = #{width.inspect}"
puts "height = #{height.inspect}"

Alternatively if you can provide a .xmz which will generate the crash that should tell me what the exact character is pretty fast. I know I've spent some time in the past trying to make sure that 'poison' characters cannot be typed into the fields, but not much in the way of validating the values already in the fields. I'll try to take a stab at making this codepath more robust, though having the exact data which causes the crash should speed that up.

@zynmuse
Copy link
Author

zynmuse commented Sep 9, 2021

I've renamed the .xmz to .zip in order for it to be accepted here.
Hope that works!

210909143320-193-Note5.zip

@fundamental
Copy link
Member

Well I can replicate the bug and it looks like it's not a bug in my code but somewhere within mruby.

Basically it gets to a line which says:

x = y = z

You'd think after this line x would hold the value of z and y would hold the value of z, no?
Somehow x is getting a value which is not the old value of x, not the value of y and not the value of z. Magical...

I just have to take the code and turn it into a minimal example, then submit the bug report to upstream mruby. They're usually very quick at fixing this sort of thing if they have a minimal example.

@fundamental
Copy link
Member

mruby/mruby#5550 Should resolve this issue.

@zynmuse
Copy link
Author

zynmuse commented Sep 10, 2021

Great news Mark. I'll try it later today.
If you are right this could solve other problems in your code and elswhere!

@fundamental
Copy link
Member

The update to MRuby has been pushed, so I've updated the submodule in mruby-zest-build. I didn't have much time to check this morning, but it appears to resolve the issue without introducing regressions.

@zynmuse
Copy link
Author

zynmuse commented Sep 10, 2021

Looking good to me so far!

@zynmuse
Copy link
Author

zynmuse commented Sep 12, 2021

I think this item can be closed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants