Zynaddsubfx crashing on instrument change

All your LV2 and LADSPA goodness and more.

Moderators: MattKingUSA, khz

User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

When a I run a 3.0.1 compile of Zyn on a fresh install of Raspbian (Debian 8, Jessie), it crashes whenever I change instruments. I tried another compile of 2.5.4 on a fresh OS install and I get the same thing, whether using the GUI or OSC messages to change instruments.

pure virtual method called
terminate called without an active exception

It was working fine from a compile I did back in June (why didn't I leave it alone?) so my guess is that a library or kernel update since then has change some library Zyn uses to change the instruments. It also might be rtosc?

Was wondering if anybody else had a similar issue with a different Linux flavor, or has also tried a recent compile on a Raspberry Pi.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Zynaddsubfx crashing on instrument change

Post by fundamental »

Could you get a backtrace using gdb? That would be much easier to diagnose.
ZynAddSubFX maintainer
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

Ok here is what I got from running zynaddsubfx in gdb. While it was running, I was able to send /noteOn, /noteOff, and /Panic through oscprompt. When I sent: /load_xiz 0 "/usr/local/share/zynaddsubfx/banks/Fantasy/0034-ImpossibleDream2.xiz" it crashed.

Code: Select all

Starting program: /usr/local/bin/zynaddsubfx -U -A=0 -a -o 512 -r 48000 -b 64 -I alsa -O jack -P 7777 -L /usr/local/share/zynaddsubfx/banks/Fantasy/0034-ImpossibleDream2.xiz
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

ZynAddSubFX - Copyright (c) 2002-2013 Nasca Octavian Paul and others
                Copyright (c) 2009-2016 Mark McCurry [active maintainer]
Compiled: Mar  3 2017 04:59:17
This program is free software (GNU GPL v2 or later) and 
it comes with ABSOLUTELY NO WARRANTY.

[New Thread 0x758fa410 (LWP 857)]
[New Thread 0x7587a410 (LWP 858)]
[Thread 0x7587a410 (LWP 858) exited]
[Thread 0x758fa410 (LWP 857) exited]

Sample Rate = 		48000
Sound Buffer Size = 	64 samples
Internal latency = 	1.3 ms
ADsynth Oscil.Size = 	512 samples
lo server running on 7777
Instrument file loaded.
[INFO] Nio::start()
Starting Audio: JACK
[New Thread 0x758fa410 (LWP 859)]
[New Thread 0x7587a410 (LWP 860)]
[New Thread 0x72dc6410 (LWP 861)]
Jack buffer resized
Audio Started
Starting MIDI: ALSA
JackEngine::XRun: client = zynaddsubfx was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = zynaddsubfx was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Jack reports xrun
Jack reports xrun
[New Thread 0x72945410 (LWP 862)]
MIDI Started
[INFO] exec-after-init
[INFO] startup OSC
[INFO] UI calbacks
[INFO] OSC replay
[INFO] auto_save setup
[INFO] NSM Stuff
[INFO] LASH Stuff
lash_init: Cannot connect to D-Bus session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
[INFO] Main Loop...
[New Thread 0x72145410 (LWP 863)]
pure virtual method called
terminate called without an active exception

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x72145410 (LWP 863)]
0x766b6f70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Zynaddsubfx crashing on instrument change

Post by fundamental »

That's almost the info that I need. After the pure virtual crash you should get the gdb prompt, could you run the command "thread apply all bt" there?

That should supply a backtrace for all the various threads.
ZynAddSubFX maintainer
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

Ah, didn't know about that. gdb is new to me and had to look up how to run it. Here is the result of that backtrace you asked for. I had to killall jackd in another session because it streamed errors after zyn crashed. So, jackd's exit may be included in the results.

Code: Select all

Thread 8 (Thread 0x72145410 (LWP 19979)):
#0  0x766b6f70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x766b8324 in __GI_abort () at abort.c:89
#2  0x768beb5c in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3  0x768bc9a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 7 (Thread 0x72945410 (LWP 898)):
#0  0x76728364 in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x767541e0 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
#2  0x00155888 in AlsaEngine::MidiThread() ()
#3  0x76aa1e90 in start_thread (arg=0x72945410) at pthread_create.c:311
#4  0x7675a598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 6 (Thread 0x72dc6410 (LWP 897)):
#0  0x76aa8c50 in do_futex_timed_wait (isem=isem@entry=0x75775000, rt=rt@entry=0x72dc5d00)
    at ../nptl/sysdeps/unix/sysv/linux/sem_timedwait.c:41
#1  0x76aa8d7c in sem_timedwait (sem=0x75775000, abstime=0x72dc5d40)
    at ../nptl/sysdeps/unix/sysv/linux/sem_timedwait.c:96
#2  0x76b1f4b8 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#3  0x76b0744c in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#4  0x76b09b34 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#5  0x76b06604 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#6  0x76b057ec in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#7  0x76b1ea84 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#8  0x76aa1e90 in start_thread (arg=0x72dc6410) at pthread_create.c:311
#9  0x7675a598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0x7587a410 (LWP 896)):
#0  0x76aa9cb0 in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x76b201b4 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#2  0x76b22a7c in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#3  0x76b1ea84 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#4  0x76aa1e90 in start_thread (arg=0x7587a410) at pthread_create.c:311
---Type <return> to continue, or q <return> to quit---
#5  0x7675a598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x758fa410 (LWP 895)):
#0  0x76aa67a4 in __pthread_cond_wait (cond=0x81e4d0, mutex=0x81e4b4) at pthread_cond_wait.c:187
#1  0x76b1f928 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x762fd000 (LWP 888)):
#0  0x76753964 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x76eff0e0 in fl_wait(double) () from /usr/lib/arm-linux-gnueabihf/libfltk.so.1.3
#2  0x76ea6638 in Fl::wait(double) () from /usr/lib/arm-linux-gnueabihf/libfltk.so.1.3
#3  0x000a6d48 in MiddleWareImpl::loadPart(int, char const*, Master*) ()
#4  0x001e34a8 in rtosc::Ports::dispatch(char const*, rtosc::RtData&, bool) const ()
#5  0x00098c70 in MiddleWareImpl::handleMsg(char const*) ()
#6  0x00099938 in handler_function(char const*, char const*, lo_arg**, int, void*, void*) ()
#7  0x76ac9f30 in ?? () from /usr/lib/liblo.so.7
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Zynaddsubfx crashing on instrument change

Post by fundamental »

Thanks for the information. Looking at the backtraces it looks like it might be one fltk UI specific corruption issue which was fixed a while back. Are you running a build of 3.0.1 that you compiled yourself from one of the tars or are you compiling from git?

I can't replicate the issue on my x86 desktop which hints that the problem is either arm specific, or it has been fixed between the version you have built and the development version I have
ZynAddSubFX maintainer
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

They have been compiled from the tar files from Sourceforge. What concerns me is that the same issue happened on a compile of 2.5.4 I tried on a fresh install. That 2.5.4 version worked fine compiled on arm Debian back in June 16. I will try a fresh install and git compile tonight. Will report back in a few hours.
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

Fresh git compile on a new os install, same problem. Below is the gdb backtrace. Bummer.

Code: Select all

Thread 8 (Thread 0x72594410 (LWP 845)):
#0  0x766c0f70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x766c2324 in __GI_abort () at abort.c:89
#2  0x768c8b5c in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3  0x768c69a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 7 (Thread 0x72d94410 (LWP 824)):
#0  0x76732364 in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x7675e1e0 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
#2  0x00155bd0 in AlsaEngine::MidiThread() ()
#3  0x76aabe90 in start_thread (arg=0x72d94410) at pthread_create.c:311
#4  0x76764598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 6 (Thread 0x72e14410 (LWP 820)):
#0  0x76ab2c50 in do_futex_timed_wait (isem=isem@entry=0x76fb4000, rt=rt@entry=0x72e13d00)
    at ../nptl/sysdeps/unix/sysv/linux/sem_timedwait.c:41
#1  0x76ab2d7c in sem_timedwait (sem=0x76fb4000, abstime=0x72e13d40)
    at ../nptl/sysdeps/unix/sysv/linux/sem_timedwait.c:96
#2  0x76b294b8 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#3  0x76b1144c in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#4  0x76b13b34 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#5  0x76b10604 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#6  0x76b0f7ec in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#7  0x76b28a84 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#8  0x76aabe90 in start_thread (arg=0x72e14410) at pthread_create.c:311
#9  0x76764598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0x75884410 (LWP 819)):
#0  0x76ab3cb0 in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x76b2a1b4 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#2  0x76b2ca7c in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#3  0x76b28a84 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#4  0x76aabe90 in start_thread (arg=0x75884410) at pthread_create.c:311
---Type <return> to continue, or q <return> to quit---
#5  0x76764598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x75904410 (LWP 818)):
#0  0x76ab07a4 in __pthread_cond_wait (cond=0x81e500, mutex=0x81e4e4) at pthread_cond_wait.c:187
#1  0x76b29928 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x76307000 (LWP 811)):
#0  0x7675d964 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x76f090e0 in fl_wait(double) () from /usr/lib/arm-linux-gnueabihf/libfltk.so.1.3
#2  0x76eb0638 in Fl::wait(double) () from /usr/lib/arm-linux-gnueabihf/libfltk.so.1.3
#3  0x000a6e08 in MiddleWareImpl::loadPart(int, char const*, Master*) ()
#4  0x001e37f0 in rtosc::Ports::dispatch(char const*, rtosc::RtData&, bool) const ()
#5  0x00098d40 in MiddleWareImpl::handleMsg(char const*) ()
#6  0x00099a08 in handler_function(char const*, char const*, lo_arg**, int, void*, void*) ()
#7  0x76ad3f30 in ?? () from /usr/lib/liblo.so.7
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Zynaddsubfx crashing on instrument change

Post by fundamental »

Hm, if the problem started with 2.5.x then it isn't the bug I was thinking of as that was a 3.0.x regression. Additionally I was thinking that there might be a mixture of different dependencies interacting, but if it happens on a fresh install, then that avenue of thought is largely eliminated. The gdb traces show that it's mid-load when the application dies which makes me think what happened is:
- a partial load
- a corruption of one of the classes involved in the load (possibly out-of-bounds memory access or a data race unique to ARM (compared to x86 and x86_64)
- a method call to one corrupted (or invalidly cast) class instances (as it shouldn't be possible to create a class instance with a pure virtual method in it

I would point my finger at the PAD synth semi-parallel initialization routine, but the patch that you can replicate the crash with does not appear to use padsynth. Lastly, I recognize what all the other threads seem to be doing, but I'm not sure what created 'Thread 8' (unless libstdc++ spawns a new thread for the termination handler).

Since I'm guessing this is a memory corruption bug I'd expect 'valgrind' to be able to detect it.
Modifying the test case you've presented, all you should need to run is:

valgrind --log-file=valgrind-output.txt /usr/local/bin/zynaddsubfx -U -A=0 -a -o 512 -r 48000 -b 64 -I alsa -O jack -P 7777 -L /usr/local/share/zynaddsubfx/banks/Fantasy/0034-ImpossibleDream2.xiz

and paste the 'valgrind-output.txt' file.

If you haven't been compiling zyn in debug mode, then I'd recommend going into the zyn build dir, running 'ccmake .' and turning 'BuildForDebug' to 'ON' (then 'c' 'g' to apply and make to rebuild/make install to update the /usr/local install).

Thanks for helping debug this issue so far.
ZynAddSubFX maintainer
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

Ok, rebuilt with BuildForDebug, installed valgrind and tried your suggestion. Got an error.

$ valgrind --log-file=valgrind-output.txt /usr/local/bin/zynaddsubfx -U -A=0 -a -o 512 -r 48000 -b 64 -I alsa -O jack -P 7777 -L /usr/local/share/zynaddsubfx/banks/Fantasy/0034-ImpossibleDream2.xiz

Illegal instruction

$ _
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

I tried running it through gbd again, now that its recompiled with BuildForDebug. Now it changes instruments without crashing. I am at a loss to explain it. I did a backtrace anyway, so you can see if there is any difference. Although somewhat good news, I have no doubt that if I started over with a fresh install and building without debug from git, that the problem would appear again.

Code: Select all

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

ZynAddSubFX - Copyright (c) 2002-2013 Nasca Octavian Paul and others
                Copyright (c) 2009-2016 Mark McCurry [active maintainer]
Compiled: Mar 23 2017 23:33:36
This program is free software (GNU GPL v2 or later) and 
it comes with ABSOLUTELY NO WARRANTY.

[New Thread 0x75904410 (LWP 836)]
[New Thread 0x75884410 (LWP 837)]
[Thread 0x75884410 (LWP 837) exited]
[Thread 0x75904410 (LWP 836) exited]

Sample Rate = 		48000
Sound Buffer Size = 	64 samples
Internal latency = 	1.3 ms
ADsynth Oscil.Size = 	512 samples
lo server running on 7777
Instrument file loaded.
[INFO] Nio::start()
Starting Audio: JACK
[New Thread 0x75904410 (LWP 838)]
[New Thread 0x75884410 (LWP 839)]
[New Thread 0x72e14410 (LWP 840)]
Jack buffer resized
Audio Started
Starting MIDI: ALSA
[New Thread 0x72d94410 (LWP 844)]
MIDI Started
[INFO] exec-after-init
[INFO] startup OSC
[INFO] UI calbacks
[INFO] OSC replay
[INFO] auto_save setup
[INFO] NSM Stuff
[INFO] LASH Stuff
lash_init: Cannot connect to D-Bus session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
[INFO] Main Loop...
Info, alsa midi port connected

[New Thread 0x72594410 (LWP 851)]
[Thread 0x72594410 (LWP 851) exited]

^C

Program received signal SIGINT, Interrupt.
0x7675d964 in select () at ../sysdeps/unix/syscall-template.S:81
81	../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) JackEngine::XRun: client = zynaddsubfx was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Jack main caught signal 15
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Released audio card Audio0
audio_reservation_finish

(gdb) thread apply all bt

Thread 7 (Thread 0x72d94410 (LWP 844)):
#0  0x76732364 in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x7675e1e0 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
#2  0x0026990c in AlsaEngine::MidiThread (this=0x9794e0) at /home/pi/zynaddsubfx/src/Nio/AlsaEngine.cpp:112
#3  0x00269888 in AlsaEngine::_MidiThread (arg=0x9794e0) at /home/pi/zynaddsubfx/src/Nio/AlsaEngine.cpp:99
#4  0x76aabe90 in start_thread (arg=0x72d94410) at pthread_create.c:311
#5  0x76764598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 6 (Thread 0x72e14410 (LWP 840)):
#0  0x76ab2c50 in do_futex_timed_wait (isem=isem@entry=0x76fb4000, rt=rt@entry=0x72e13d00)
    at ../nptl/sysdeps/unix/sysv/linux/sem_timedwait.c:41
#1  0x76ab2d7c in sem_timedwait (sem=0x76fb4000, abstime=0x72e13d40)
    at ../nptl/sysdeps/unix/sysv/linux/sem_timedwait.c:96
#2  0x76b294b8 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#3  0x76b1144c in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#4  0x76b13b34 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#5  0x76b10604 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#6  0x76b0f7ec in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#7  0x76b28a84 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#8  0x76aabe90 in start_thread (arg=0x72e14410) at pthread_create.c:311
#9  0x76764598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0x75884410 (LWP 839)):
#0  0x76ab3cb0 in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x76b2a1b4 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#2  0x76b2ca7c in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#3  0x76b28a84 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#4  0x76aabe90 in start_thread (arg=0x75884410) at pthread_create.c:311
#5  0x76764598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x75904410 (LWP 838)):
#0  0x76ab07a4 in __pthread_cond_wait (cond=0x98b4c8, mutex=0x98b4ac) at pthread_cond_wait.c:187
---Type <return> to continue, or q <return> to quit---
#1  0x76b29928 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x76307000 (LWP 830)):
#0  0x7675d964 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x76f090e0 in fl_wait(double) () from /usr/lib/arm-linux-gnueabihf/libfltk.so.1.3
#2  0x76eb0638 in Fl::wait(double) () from /usr/lib/arm-linux-gnueabihf/libfltk.so.1.3
#3  0x0026fc60 in GUI::tickUi () at /home/pi/zynaddsubfx/src/UI/Connection.cpp:274
#4  0x000ca0d8 in main (argc=18, argv=0x7efff6c4) at /home/pi/zynaddsubfx/src/main.cpp:679
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Zynaddsubfx crashing on instrument change

Post by fundamental »

Excellent, you appear to have a working build. Setting the build to use debug compiler flags does 2 things.

1. It removes general optimizations -O3 -ffast-math -fomit-frame-pointer
2. It removes ARM specific optimizations https://github.com/zynaddsubfx/zynaddsu ... s.txt#L193
3. (in the case of compiler detection going very wrong since you're on ARM) It removes SSE optimizations https://github.com/zynaddsubfx/zynaddsu ... s.txt#L197


Since changing optimizations appears to fix the issue, I would say the root cause is either:

1. Undefined behavior that is ARM specific due to memory model differences
2. Raspberry Pi revision differences (I don't know if you specified Pi2/Pi3/etc). This would be fixed by setting 'NoNeonPlease' to ON (at which point it should be safe to return 'BuildForDebug' to OFF)
3. A possible compiler bug (unlikely, but I have encountered one every 2-3 years or so when dealing with zyn+optimizations)

I'm guessing that the second case is the most likely (and it's the easiest to check). If it doesn't work, then the no-optimization build should still work, though it will be a fair bit slower.

In case there's any information from the valgrind run, could you paste the valgrind output which should have been written to the 'valgrind-output.txt' file?

Thanks for your patients
ZynAddSubFX maintainer
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

Ok, lots of trial and error and compiling with various options. Was about to give up. But, I have a stable build running now.

Your suggestion of 'NoNeonPlease' didn't work by itself, but it reminded me of a problem I had with an old version of Zyn that was trying to compile using SSE2 and would fail because it doesn't exist. I had to edit the actual makefile to get rid of it. So, I tried removing the SSE options even though cmake reported SSE test fail. That didn't work either.

But, choosing 'NoNeonPlease' AND removing the options from the SSE optimizations field in ccmake, it now works fine. My only guess is that the automatic options for each are failing to correctly identify the hardware context.

I also read somewhere that newer ARM processors have NEON baked in as opposed to a distinct subprocessor, but the namespaces have changed.

Now that it's working, I'm moving on to building a small web app in node to change the instruments. I had that running before and used my phone to select instruments.

Would love ask some OSC questions if you're up to it. The API docs are useful, but difficult to decipher for practical use.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Zynaddsubfx crashing on instrument change

Post by fundamental »

My only guess is that the automatic options for each are failing to correctly identify the hardware context.
That sounds entirely consistent with what has been discussed. As such I've added it to the bug tracker for when myself or another dev gets access to an ARM system for debugging the cmake script: https://sourceforge.net/p/zynaddsubfx/bugs/153/

Both the SSE and NEON support detectors were added as a patch a year or so ago and I was never able to fully test them due to a lack of setup hardware. I guess it turns out that they do *not* work after all. :-/

As a last bit of information to document this issue, could you post "cmake --version" and "gcc --version" (or "clang --version" if using clang to build) on your affected system?

Would love ask some OSC questions if you're up to it. The API docs are useful, but difficult to decipher for practical use.
Sure thing, ask away.
ZynAddSubFX maintainer
User avatar
lucidbeaming
Established Member
Posts: 34
Joined: Tue Mar 21, 2017 8:44 am
Location: San Jose, CA
Contact:

Re: Zynaddsubfx crashing on instrument change

Post by lucidbeaming »

Ok, a few OSC goals for this small web app. What I'd like to have is a simple way of switching effects on and off on a global level, as well as basic filter cutoff, resonance, and global envelope control. Some of that is for expression, but also to simplify complex instruments that give XRUNs when played to fast. The cutoff, resonance, etc. can be controlled from midi controls.

I think if I had a way of intercepting the OSC messages from the GUI to the backend, I could probably reverse engineer the address/msg packages. I tried a loopback port scanner, but couldn't get the OSC packages out. I'm fine with oscprompt, but as you say in the readme, OSC isn't exactly a verbose protocol for debugging.

for effects:

/sysefx[0,3]/efftype i
/sysefx[0,3]/preset i

those are straightforward, but I can't figure out the address for sysefx amount [0,3] for the current instrument, maybe /Psysefxvol[0,3]/part[0,15] i) thought it would be simple.

ADSR:

From what I can tell, each of the instrument synth types (AD,PAD,SUB) have their own ADSR envelopes, but there isn't a global amplitude envelope that can be set with OSC. Is that the case?

XRUNS:

I have an excellent sound card for the Raspberry, but can't go above 48000khz because I get XRUNS. I have tried all sorts of jackd/zyn parameters and I think there just isn't enough horsepower for certain instruments. But, If could send an OSC message(s) that turns off all reverb/delay insfx and sysfx I think those instruments would play fine. I have enough outboard effects to make up for that if I shut them off. Any suggested strategies?

Btw, thanks for your help. Glad to have this up and running again.
Post Reply