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
Comments
I ran this under valgrind and it lasted for much longer before it exited again. |
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. |
I ran this under valgrind and it lasted for much longer before it exited again. |
Rephrasing - The two crashes resulting in:
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. |
Can't say exactly what was happening. 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. |
This problem is still present in the current master of 6 September.. I can restart zest and carry on.(gdb) r |
Could I put a break point somewhere to get some useful stack information? |
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. |
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. |
Thanks for that. |
HERE'S A BACKTRACE FROM THIS POBLEM
|
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. |
If I clone the master again now will I pick up your latest update? |
If I clone the master again now will I pick up your latest update?
Yes
… |
OK |
I THINK THIS IS WHAT YOU NEED |
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! 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? |
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:
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. |
I've renamed the .xmz to .zip in order for it to be accepted here. |
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:
You'd think after this line x would hold the value of z and y would hold the value of z, no? 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. |
mruby/mruby#5550 Should resolve this issue. |
Great news Mark. I'll try it later today. |
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. |
Looking good to me so far! |
I think this item can be closed now. |
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)
============================================================================================
The text was updated successfully, but these errors were encountered: