Zyn-fusion crash (different to last one)

[zynmuse]

I was adjusting Adaptive Harmonic parameters in the Oscillator screen. This was causing the right hand graph to change a lot. Core dumped.

[debug] parsing json file
[debug] json parsed succesfully
Time for a fast load is 1.504ms load(0.004) class(0.001) spawn(1.499)...
making reverse graph[1103]<0.817 ms>
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
trace (most recent call last):
    [16] (unknown):0
    [15] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:538:in draw
    [14] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/time-profile.rb:24:in time
    [13] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:539:in draw
    [12] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:139:in render
    [11] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrblib/range.rb:45:in each
    [10] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:159:in render
    [9] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/deps/mruby-nanovg/mrblib/context.rb:90:in draw
    [8] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:160:in render
    [7] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrblib/array.rb:17:in each
    [6] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:162:in render
    [5] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/deps/mruby-nanovg/mrblib/context.rb:116:in spork
    [4] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:164:in render
    [3] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:10588:in draw
    [2] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:10577:in cv
    [1] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:10575:in rap2dB
/JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:10575:in log10: non float value (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue
[Inferior 1 (process 2977) exited with code 01]
No stack.

[fundamental]

Mind attaching your fcache.rb file? You should be able to just rename it to fcache.txt if github balks.

The generation of that should be deterministic, but this issue like the last one doesn't seem to have the function I'd expect based on the backtrace (in this case at fcache.rb:10588 ) The cv() call narrows it down to 3 widgets, VuMeter, ZynMixerCol, and ZynMasterMixerCol.

[fundamental]

Based upon where you observed the crash only the VuMeter was on screen, so that would be the one to be suspicious of. Looking at the code in question as well as mruby's Math::log10 behavior, it makes it look like somehow OSC bridge must have passed VuMeter a string instead of a floating point array. To me that points to

Note math::log10(float) works for typical floats, NaN, Inf, Math::log10(int) works just fine, Math::log10(symbol/class/etc) gives a different error, Math::log10(string) gives the error. In VuMeter.qml it checks if data is nil, then if it's non-nil it passes data[0] and data[1] into cv which passes things into Math::log10 if data is anything other than a string I can't see this error occuring (String[int]->String in ruby).

[fundamental]

If a string is being provided to the Ruby layer it's either:

1. Corruption of the cache within osc-bridge
2. Mishandling of a corrupted message within osc-bridge
3. Corruption of a message going into the realtime->non-realtime thread buffer in the zynaddsubfx process
4. Mangling of the message when sending it from the zynaddsubfx process.
5. Corruption of the data in the Ruby VM (resulting in the floating point data vector getting switched to a string pointer)
6. Something I haven't thought of

There's fairly direct ways to instrument and trace the cause backwards for any of the above causes if there's a semi-reliable way of triggering the issue.

[zynmuse]

fcatch.rb attached fcache.txt

[zynmuse]

I've spent a lot of time playing with sounds today, and only the one crash. It's not repeatable. Can I put a breakpoint anywhere to give more info if it happens again?

[zynmuse]

I have almost zero knowledge of ruby syntax. Is it possible to temporarily alter the code somehow to detect an unexpected string (or non-float) value (at one or more places) and print the string to trrminal and then exit. I'm happy to alter my source locally and then run with it until this happens again - pretty much how we solved the a=b=c problem.

[fundamental]

Is it possible to temporarily alter the code somehow to detect an unexpected string

Yes, but that would be altering the code expecting a certain value to be wrong. If every time there's an error it's in a different location, then we're stuck. If it does look like it's the same value having issues, then the basic workflow that I throw in is:

puts("x.class = #{x.class}")
puts("x          = #{x.inspect})

Where the value is received (where x is the variable). If you can get the variable to print as a string class, then it's pretty straightforward to raise an error there (raise Exception.new("message")), turn that into a C breakpoint where the MRuby VM instantiates the exception class, then see if remote_cb_str() is called from remote_cb (src/mruby-widget-lib/src/gem.c:831). If that's called, then it's tracing things back to run_callbacks(bridge.c) to check the status of the parameter line and the destination. remote_cb should have enough information in the message to show if it's a string and if it's from the correct location (messages have a 'path' attached to them).

Can I put a breakpoint anywhere ELSE to give more info if it happens again?

Yes. It is possible to reduce the search space significantly. When an error is raised it isn't a full crash, but the VM gets an error and the program cleanly exists as that should not happen and if it does happen the program is in an unknown state. So, src/mruby-widget-lib/src/api.c:47 is only reached when a 'fatal error' has occurred. At that point all of the data is still floating around. Right now the only way to get access to the osc-bridge data structures is through a ruby VM call, but with a tiny modification it should be easy to leave yourself a pointer into those structures.

In src/mruby-widget-lib/src/gem.c:454 you can save that pointer to a global value (e.g. bridge_t *remember_me_for_later;...mrb_remote_initialize()...remember_me_for_later = data->br;).

Then when you hit the failure state it's a matter of checking the right value. bridge_t in this case has param_cache_t which should contain the currently known values of everything it has recently received. In there you can check a value if you know the OSC handle. Pretty involved, but it's the general approach to checking things. It's also feasible to create some method for dumping the osc-bridge's full content, but that has not been written thus far. A more concise version would be to dump anything associated with what's currently on-screen by referencing the callback datastructure.

Depending on the sorts of above investigation it will say if the problem is on the ruby side or if it's on the osc-bridge side. From there if a given parameter does corrupt on the osc-bridge side from time to time it's a matter of capturing the corrupting event. That's basically going to be waiting for a message with the path and dumping the message size, and all the bytes. If the message is ill formed it should be rejected rather than cause issues. If the message is well formed and contains the 'wrong' data, then the issue is likely on zyn's side.

[fundamental]

Basically it's a somewhat multi-stage sanity check. I do find this issue the most promising in the goose chasing though as the vu meters are updated a few times a second, so they're the most likely to have something go wrong even if they're not the source of the issue. In terms of automating this if there's a known fault below the MRuby level, then it may be possible to detect a cache line changing types with a new message and then providing a place to hook on a gdb breakpoint there. Everything depends upon where the error is happening though.

[zynmuse]

If i understand you I'm best to add 2 lines in src/mruby-widget-lib/src/gem.c

1. before definition of mrb_remote_initialize(); _bridge_t *rememberme;
2. after the line data->br = br_create(arg); _rememberme = data->br;

and a breakpoint at src/mruby-widget-lib/src/api.c:47

If I hit the breakpojnt then I can observe the structure _rememberme

[fundamental]

yep

[zynmuse]

I've made those changes and running with the breakopoint. No problems yet!

[zynmuse]

Ive got a stack trace with the full contents of mrb listed. At the time of the crash I was not making and changes via the UI, but some synths were playing and there was some automation. I notices the display had frozen.

ZynFusionCrash.20210924.txt

I also have saved a core file but it's 250mByte so maybe to big to post here. If it is any use to you please let me know.

[fundamental]

Did it crash or did it freeze and you attempted to exit it? The backtrace looks entirely normal, it's setting up for redrawing the envelope visualization with 2 running notes. If there was a crash the text file doesn't include where the error gets printed out which is just a line or two below the breakpoint in api.c that you used. If there was a crash about failing to convert types related to the backtrace, then going into the osc-bridge cache and looking at the value of the "/part7/kit0/adpars/VoicePar1/AmpEnvelope/out" field would be quite helpful. the remote_cb_fvec() should have been triggered with four floats, but if there's something wrong with the cache line then I could see that causing issues. In general the 'mrb' pointer does not contain useful information.

[zynmuse]

Hi Yes it crashed.

I had automated the set up of the breakpoint every time I start zyn-fusion by passing it as a parameter in my start script, so gdb appears to report it after the stack trace, but that wasn't where the program crashed.

Breakpoint 1 at 0x7ffff7862e10: file /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/src/api.c, line 47.

but segmentation fault was at class.c:1740

Program received signal SIGSEGV, Segmentation fault. mrb_method_search_vm (mrb=0x5555559b58b0, cp=cp@entry=0x7fffffff55c8, mid=894) at /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/src/class.c:1740 1740 struct mt_elem *e = mt_get(mrb, h, mid);

Sorry if I missed that off the listing I sent you!

====== Sorry for my ignorance but where would I find the osc-bridge cache? I suspect I've altered things since the crash as I have run fusion again. For the next crash I have I could save cache files in case you need them. I need to build up a list of data that I can gather when I next have a crash.

[fundamental]

Hmmm. Now I have absolutely zero rational why you'd get a segfault there. Either it's a MRuby bug deep in the internals or it's corruption of a MRuby related datastructure. Running with valgrind will help find the latter, but it will slow the execution down significantly. There's also the address sanitizer which I think has less of a performance penalty, though I use it less often.

Per the osc-bridge cache it's src/osc-bridge/src/cache.c/cache.h . Given that this is a segfault where no segfault should be able to occur I suspect one of the two previous techniques (valgrind/sanitizer) will be necessary.

[zynmuse]

Thanks for the reply. Unfortunately this crash was not repeatable.

1. I'll have a go at running under valgrind but it will probably make the system too slow to use on my system. I can confirm this having now tried it!

2. I'll try the address sanitizer. I haven't heard of it before. CAN YOU TELL ME HOW TO INCORPORATE THIS TOOL INTO THE MAKEFILE IN ORDER TO REBUILD?

3. I'll try to remember to save the cache files with any future crash just in case!

[zynmuse]

I don't understand your instruction on cache file (from above). cache.c is empty. cache.h is the header from when the master was downloaded. I did run with valgrind for a while yesterday. It did produce a leak-log.txt file. Its about 500k. Not sure if that would have any useful information?

[fundamental]

https://github.com/mruby-zest/mruby-zest-build/blob/master/src/osc-bridge/src/bridge.c#L17-L186 contains the code which uses the cache, cache.h defines the datastructures. If your valgrind file has found memory violations that aren't coming from the pugl layer, then they're of interest, any leaks would not be of interest and a lot of memory will likely look like it was leaked if the system was shutdown in an unclean fashion.

Also, general FYI, I usually watch the issue tracker by email and I do not see edits like in the previous post.

per the address sanitizer, pages like https://clang.llvm.org/docs/AddressSanitizer.html indicate that it involves -fsanitize=address -fno-omit-frame-pointer during compilation and -fsanitize=address during linking when using clang. I recall the process being similar with gcc last time I did it. Of note I have not personally run the address sanitizer in quite some time, though it is a useful tool.

[zynmuse]

I generally shudown the zest program using the X box on the right of the window titlebar. I expect that would give a clean shutdown. I didn't experience any crash whilst running under valgrind, but the zest was too slow to be useful so I didn't run it for long.

I'll check the leak-log.txt file again.

I note your second point and will not edit the issue log again.

I'll check the html reference for address sanitizer. I assume I can add the additional directives in the linux: section of mruby-zest-build/Makefile? and then recompile

[zynmuse]

Address sanitizer is a rather useful tool! I quickly found three bugs in my own program using it. gcc works with same flags as clang. I've been running zest interface with address sanitizer and it hasn't shown up any problems. I've been getting lost osc messages probably due to the extra loading (notably note-off messages being lost resulting in hanging notes), so I'll have to switch out the address sanitizer and hopefully that will return to normal.

[fundamental]

One other place to make sure that the address sanitizer is active is the osc-bridge component. Namely mruby-zest-build/src/osc-bridge/Makefile . If I recall correctly, that makefile respects CFLAGS, but depending upon how you added the address sanitizer I could forsee it missing that component. I think that if the sanitizer is working there that also covers rtosc.c, but I no longer have all of the bits of the build system memorized and usually have to hunt around to check those sorts of things.

Too bad it's not pointing out anything obvious so far. One or two good alerts from that or valgrind could point to the root cause of your crash.

[zynmuse]

Ive been trying for hours to get the osc-bridge library built with with the address-sanitizer flags to link into the mruby-zest-build makefile.

I've tried many changes and still end up with hundreds of undefined references to _asin.......

Had to give up for now!

=== EXTRACT=========================
CC    build/host/mrbgems/mruby-widget-lib/gem_init.c -> build/host/mrbgems/mruby-widget-lib/gem_init.o
AR    build/host/lib/libmruby.a 
LD    build/host/bin/mruby 
/usr/bin/ld: /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/../src/osc-bridge//libosc-bridge.a(bridge.o): in function `send_cb':
/JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/osc-bridge/src/bridge.c:292: undefined reference to `__asan_report_load8'
/usr/bin/ld: /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/../src/osc-bridge//libosc-bridge.a(bridge.o): in function `alloc_buffer':
=====================================

[zynmuse]

SRC = src/bridge.c src/cache.c src/parse-schema.c src/schema.c rtosc/rtosc.c
#Original#CFLAGS_ = -std=gnu99 -Wall -Wextra -I .
CFLAGS_ = -O1 -fsanitize=address -fno-omit-frame-pointer -std=gnu99 -Wall -Wextra -I .

all: mock-test remote-test lib

mock-test: $(SRC) test/mock-test.c
    $(CC) $(CFLAGS) $(CFLAGS_) -o mock-test $(SRC) test/mock-test.c -luv -g -O0

remote-test: $(SRC) test/basic-remote.c
    $(CC) $(CFLAGS) $(CFLAGS_) -o remote-test $(SRC) test/basic-remote.c -luv -g -O0

lib: $(SRC)
##  $(CC)  $(CFLAGS) $(CFLAGS_) -O3 -g -fPIC -c $(SRC)
    $(CC)  $(CFLAGS) $(CFLAGS_) -g -fPIC -c $(SRC)
    $(AR) rcs libosc-bridge.a bridge.o cache.o parse-schema.o schema.o rtosc.o

clean:
    rm -f libosc-bridge.a bridge.o cache.o parse-schema.o schema.o remote-test mock-test

[fundamental]

diff --git a/build_config.rb b/build_config.rb
index e72b5ab..bcc3ff8 100644
--- a/build_config.rb
+++ b/build_config.rb
@@ -129,6 +129,8 @@ build_type.new(build_name) do |conf|
       cc.include_paths << "/usr/x86_64-w64-mingw32/include/" if windows
       cc.flags << "-DLDBL_EPSILON=1e-6" if windows
       cc.flags << "-std=gnu99"
+      cc.flags << "-fsanitize=address"
+      cc.flags << "-fno-omit-frame-pointer"
       cc.flags << " -fPIC"              if !windows
       cc.flags << "-DWINDOWS_WHY"       if windows
       cc.flags << "-mstackrealign"      if windows
@@ -146,6 +148,7 @@ build_type.new(build_name) do |conf|
       linker.library_paths  << "#{`pwd`.strip}/../src/osc-bridge/"
       linker.libraries << 'osc-bridge'
       linker.flags_after_libraries  << "#{`pwd`.strip}/../deps/libnanovg.a"
+      linker.flags_after_libraries  << "-fsanitize=address"
       if(!windows)
         if(!mac)
           linker.libraries << 'GL'

Note, I do not claim that the address sanitizer will find the bug, nor do I routinely use it, but it may yield some results for you.

[zynmuse]

Thank you. I hadn't found the build_config.rb file! The zest system has now fully compiled with the sanitize flags. The system runs at a reasonable pace but hasn't crashed.

I'll add a temporary memory problem to the code to check that is working!

I'll run with this for a while and maybe it will find a problem.

[zynmuse]

Is there an easy way to get all files built with the -g switch for debugging with gdb. This used to work (at least I had this working before) but I think the old cmake mechanism had a flag to set this up. I've tried adding cc.flags << "-g" in the file build-config.rb. But that didn't add any debug data into the libraries. I'm trying to understand the configuration myself, but I'm not making much progress, and I'm making too many changes. When I reach the trial and error point I may as well ask for help!

[fundamental]

Making sure -g is in build_config.rb and osc-bridge's makefile is about as good as things get

On Fri, Oct 1, 2021, 3:25 PM John Neil Hutchinson @.***> wrote:

Is there an easy way to get all files built with the -g switch for debugging with gdb. This used to work (at least I had this working before) but I think the old cmake mechanism had a flag to set this up. I've tried adding cc.flags << "-g" in the file build-config.rb. But that didn't add any debug data into the libraries. I'm trying to understand the configuration myself, but I'm not making much progress, and I'm making too many changes. When I reach the trial and error point I may as well ask for help!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zynaddsubfx/zyn-fusion-issues/issues/307#issuecomment-932494270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF3FHO2QP3ZDO4XT4EU443UEYDL3ANCNFSM5EJMZZQA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[zynmuse]

When I built the Zest using make linux in MRuby-zest-build. It appeared to build everyhing, but didn't pick up the bug I added into the code. After some hours of trying to understand what was going on, I found that zest at startup was using to the wrong version of libzest.so. It was failing to attach the local version and was defaulting to the version /opt/zyn-fusion/libzest.so.

In order to fix this I had to add the sanitize flags directly into the Mruby-zest/build/Makefile:

linux: ruby ./rebuild-fcache.rb cd deps/nanovg/src && $(CC) nanovg.c -c -g -fPIC $(AR) rc deps/libnanovg.a deps/nanovg/src/*.o cd deps/mruby-file-stat/src && ../configure cd src/osc-bridge && make lib

cd mruby && UI_HOTLOAD=1 MRUBY_CONFIG=../build_config.rb rake

force rebuilding all code that depends on hotloading.

touch src/mruby-widget-lib/src/api.c  
cd mruby             && $(HOTLOADING) MRUBY_CONFIG=../build_config.rb rake
$(CC) -shared -o libzest.so `find mruby/build/host -type f | grep -v mrbc | grep -e "\.o$$" | grep -v bin` ./deps/libnanovg.a \
    ./deps/libnanovg.a \
    ./src/osc-bridge/libosc-bridge.a \
    `pkg-config --libs libuv` -lm -g -lX11 -lGL -lpthread  -fsanitize=address -fno-omit-frame-pointer
$(CC) test-libversion.c deps/pugl/pugl/pugl_x11.c \
      -DPUGL_HAVE_GL \
      -ldl -o zest -g -lX11 -lGL -lpthread -I deps/pugl -std=gnu99 -Wno-trigraphs   -fsanitize=address -fno-omit-frame-pointer

---

There is probably a way of ensuring the flags get picked up here, and also a switch to turn on/off the sanitize=address code would be useful addition - at a higher level. It's beyond my ability to figure that out. For now I am running and have tested that this will abort on a memory fault. I also have added (possible more than required) -g flags, so should also be able to get a stack trace if I see another crash.

[zynmuse]

Memory problem found by memory-sanitizer. Trying to select comb filter (for the first time). This is repeatable. Caused by addsynth - voice1- filter - comb.

ZestCrash-Switch to comb filter-2021-oct-02.txt

[fundamental]

I don't see the above behavior in addsynth voice1 filter comb, I do observe something similar in effects/dynamic filter scrolling over filter type during the transition into the formant filter.

What's happening is that the osc-bridge is running callbacks, then the list of callbacks grows invalidating the iteration over the list of callbacks. While running callbacks the list should never grow or shrink, so that particular callback needs to be fixed.

I've run through the whole GUI and so far the only spot I've seen generate the realloc() during use bug is in the dynamic filter formant change, so I'm fixing that though I might stumble across some other bugs while fixing this one.

[fundamental]

Looks like I've got the add synth one replicating now, time to patch that as well.

[fundamental]

Should be fixed and pushed. Note that the errors shown so far are just invalid reads which are comparatively minor when there could be invalid writes lurking out there. If your crashes go away then this is the bug, but if not then this was likely a minor red herring.

[zynmuse]

Good news is you are making some progress. Even invalid reads ought to be fixed as they may show up somewhere as a problem to the user. Learning about the santitize flag is the most useful thing to come out of this for me. I will certainly continue to use it.

Possibly significant, I have noticed over a period of heavy use the zyn-fusion display will slow down. Stopping and restarting zyn-fusion will make it speed up again. I wonder if this is due to your callback list growing - as mentioned above.

I'll grab the latest master and carry on testing.

[fundamental]

The slowdown is almost certainly the logging done in UiEventSeq in src/mruby-widget-lib/mrblib/ui-event.rb If you search this issue tracker you should see a previous comment of mine detailing how to disable the logging over time.

[zynmuse]

I assume you are referring to issue #247 Possible memory leak? #247

[fundamental]

yep

[zynmuse]

That code shouldn't be left in without some management to limit the size! I've commented it out locally for now

[zynmuse]

Sorry to continue this very long thread. Having provoked a crash similar to this one and found a remedy I now know that this crash ( in Log10 function) can be caused by confusing an integer osc port (which is actually type 'i' and requires an additional value argument as if it is a boolean (type 'T', type 'F' ). I guess the missing expected integer value will be filled by garbage which may cause the crash.

I had found this by adding an additional config parameter in zynaddsubfx/src/misc/config.cpp round about line 53 I had added: rParamI(cfg.SaveFullXml, "Include Disabled parts in save"), which cause a problem in zest when I tried to display it as a toggle

The correct configuration which fixed the problem in zest was to use: rToggle(cfg.SaveFullXml, "Include Disabled parts in save"),

It should be noted that toggling this parameter from the zest display didn't immediately cause the crash. After three or for toggles it would crash.

[fundamental]

I have attempted to replicate by changing the stereo swap port to a rParamI from a rToggle. I was unable to get the GUI to crash, nor did I succeed in getting any warnings of invalid activity from valgrind while changing the button repeatedly in the UI.

[zynmuse]

Sorry if I (incorrectly) think I understand how the system hangs together. I'm still trying to find my way around. I'm going to make your change and see the effect. Then I'm going to reverse out my (fix) and see the effect. Then I'll get back to you.

[fundamental]

No problem. As long as I have something on my system which shouldn't crash but does trigger a crash I'll use that to bug hunt.

[zynmuse]

Is there a quick way to recompile just the zynaddsubfx?

If I make any changes in zynaddsubfx/.... I'm using: make MODE=release -f Makefile.linux.mk build_zynaddsubfx

which takes ages!

Then if I make any changes to the zest, I cd into folder src/mruby-zest-build and just run: make

which is much quicker!

I run the zest from mruby-zest build - which I hope will be compatible with the zyn??

I'm getting some strange crashes of zest which I wasn't getting yesterday which I can't explain.

[fundamental]

Is there a quick way to recompile just the zynaddsubfx?

Yep. During development I just have a zynaddsubfx repo checked out. When starting it just launch it from the build directory with zynaddsubfx -U -O null -I null -P 1337 and separately launch the GUI (-P 1337 as the GUI defaults to that port)

[fundamental]

the GUI from mruby-zest-build can get out of sync with the backend, but not in a way which should induce crashes. Generally the biggest thing is making sure the OSC schema is in sync (see zynaddsubfx --help for how to generate a new copy of that), but even with an out of data schema the backend should never end up crashing.

[zynmuse]

How would I rebuild the zynaddsubfx after just changing a single file.

[zynmuse]

Actually the info I need mat be in doc/built.txt. I'll check that tomorrow. I think I've been running the cmake every time which is overkill!

[zynmuse]

Having rebuilt zynaddsubfx again in the zynaddsubfx folder and copied the latest schema from zyn to zest I now don't have any problem with my new configuration option. I can't replicate the crash I was having yesterday!

[fundamental]

I can't replicate the crash I was having yesterday!

Curious.

[zynmuse]

FYI I still frequently get the zest aborting with the stack trace similar to that at the top of this issue. I'm running with pretty much the current versions of the master and zest. Just small changes to add the SaveFullXml parameter ( which wasn't there when I first saw the crash). It could be something I have done. However looking at the trace is does now point to VuMeter as in your earlier comment.

trace (most recent call last): [16] (unknown):0 [15] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:538:in draw [14] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/time-profile.rb:24:in time [13] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:539:in draw [12] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:139:in render [11] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrblib/range.rb:45:in each [10] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:159:in render [9] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/deps/mruby-nanovg/mrblib/context.rb:90:in draw [8] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:160:in render [7] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/mruby/mrblib/array.rb:17:in each [6] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:162:in render [5] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/deps/mruby-nanovg/mrblib/context.rb:116:in spork [4] /JohnsMounts/PDevelopmentB/ZynAddSubFx_SourceCode/master/src/mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:164:in render [3] src/mruby-zest/example/VuMeter.qml:25:in draw [2] src/mruby-zest/example/VuMeter.qml:13:in cv [1] src/mruby-zest/example/VuMeter.qml:11:in rap2dB src/mruby-zest/example/VuMeter.qml:11:in log10: non float value (TypeError) [FATAL ERROR] Mruby Is Unable To Continue [Inferior 1 (process 35375) exited with code 01] No stack.

[fundamental]

Excellent. Crashes are bad, but this being a repeatable crash does help narrow things down quite a bit.

The below code will dump a bunch of info to the console. Right before the crash I'm going to guess that it's going to show a string, which will likely get back to something being wrong in the osc-bridge cache where either a string got into the VU meter parameter or the wrong callback was invoked. Keep in mind that if you're working on a development copy you're going to ensure that the previous fix is applied to the osc-bridge in your checkout.

diff --git a/src/mruby-zest/example/VuMeter.qml b/src/mruby-zest/example/VuMeter.qml
index 8df920f..d2c558a 100644
--- a/src/mruby-zest/example/VuMeter.qml
+++ b/src/mruby-zest/example/VuMeter.qml
@@ -21,6 +21,8 @@ Widget {
         pad2 = (h-2*pad)
         v1 = 0.3
         v2 = 0.5
+        puts("VuMeter Data:")
+        puts(data.inspect)
         if(!data.nil?)
             v1 = cv(data[0])
             v2 = cv(data[1])
@@ -41,6 +43,8 @@ Widget {

     function update_data(x)
     {
+        puts("VuMeter update_data")
+        puts(x.inspect())
         if(self.data != x)
             self.data = x
             self.damage_self