How recent of a gcc does Manjaro use? It seems this may be either sandy bridge CPU peculiarity (there was another one pertaining to locking and unlocking where double unlock on a pthread caused crash on sandy bridge but no other cpus) where it may be more sensitive to things programmers should not be doing in the first place, or this may stem from the increased sensitivity in the new gcc.

At any rate, after studying the code, it seems that a struct settings is instantiated (containing all the default init settings for the synth), passed along to instantiate the synth but then also immediately afterwards it is freed even though the synth instantiates multiple threads and it may be that the data is freed before the other potential thread that may be in charge of actually instantiating the synth may be done reading data within it (I haven't had a chance to study the code enough to fully understand how the threading is done within the libfluidsynth itself). At any rate, I changed the fluid~ code now where settings is a private member of the class and is freed only once the actual entire synth is freed, which should hopefully also solve the problem of the memory leak.

Best,

Ico

On 5/23/2016 7:39 AM, Albert Graef wrote:

Hi Ico,

I just tested it on Manjaro (Arch) 64 bit, using various different soundfonts and fluidsynth 1.1.6 and it works without a hitch for me. Maybe a broken libfluidsynth on Ubuntu?

Albert

On Mon, May 23, 2016 at 12:31 AM, Ivica Bukvic <ico@vt.edu mailto:ico@vt.edu> wrote:

All,

It appears since sometime earlier this year (possibly with upgrade
to Ubuntu 15.10 and newer), fluid~ external crashes as soon as you
enable dac~. It worked perfectly fine before. The backtrace is
fairly cryptic suggesting something is wrong with the
libfluidsynth. Yet, other apps that use it work just fine (e.g.
Qsynth). To make matters more complicated, fluid~ uses flext
library, although other externals work fine with the current
version of flext.

Below is the gdb backtrace:

#0  0x0000000000000000 in ?? ()
#1  0x00007fffdab6e691 in fluid_hashtable_lookup ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#2  0x00007fffdab6f51e in ?? ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#3  0x00007fffdab71448 in fluid_settings_getint ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#4  0x00007fffdab6a026 in fluid_LADSPA_run ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#5  0x00007fffdab7d3b7 in fluid_rvoice_mixer_render ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#6  0x00007fffdab8399d in fluid_synth_write_float ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#7  0x00007fffdae28908 in fluid::m_signal(int, float* const*,
float* const*) ()
   from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux
#8  0x00007fffdae29fcb in flext_dsp_multi::dspmeth(long*) ()
   from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux
#9  0x00000000004b3bc5 in dsp_tick () at d_ugen.c:336
#10 0x00000000004a3093 in sched_tick () at m_sched.c:385
#11 0x00000000004a34be in m_pollingscheduler () at m_sched.c:485
#12 m_mainloop () at m_sched.c:563

Is this a know issue? It wasn't a problem until I upgraded to
15.10 (from 14.04) and it seems 16.04 (64bit) is also problematic.
Has anyone had any luck recently with the fluid~ external?

_______________________________________________
L2Ork-dev mailing list
L2Ork-dev@disis.music.vt.edu <mailto:L2Ork-dev@disis.music.vt.edu>
http://disis.music.vt.edu/listinfo/l2ork-dev

-- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggraef@gmail.com mailto:aggraef@gmail.com WWW: https://plus.google.com/+AlbertGraef

---

L2Ork-dev mailing list L2Ork-dev@disis.music.vt.edu http://disis.music.vt.edu/listinfo/l2ork-dev