[L2Ork-dev] problems with footils fluid~

Mon May 23 17:09:48 UTC 2016

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 at vt.edu 
> <mailto:ico at 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 at disis.music.vt.edu <mailto:L2Ork-dev at 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 at gmail.com <mailto:aggraef at gmail.com>
> WWW: https://plus.google.com/+AlbertGraef
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20160523/2f7dc107/attachment.html>