Crash on File Open

39 replies [Last post]
kbrown
User offline. Last seen 24 weeks 3 days ago. Offline
Joined: 2013-11-09
Posts:

Hi,

I'm running Ardour 3.5.380 on Ubuntu 14.04. Just a few days ago I created a new session and everything was working just fine. Now every time I try to open that session Ardour crashes with the following message:

*** Error in `/opt/Ardour-3.5.380-dbg/bin/ardour-3.5.380': corrupted double-linked list: 0x00007f570800e590 ***
Aborted (core dumped)

I'll post a full back trace in a reply as it's so long...

kbrown
User offline. Last seen 24 weeks 3 days ago. Offline
Joined: 2013-11-09
Posts:

Here's the back trace. Hope someone can help me as I'd really like to salvage that session...:

GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/Ardour-3.5.380-dbg/bin/ardour-3.5.380...done.
(gdb) run
Starting program: /opt/Ardour-3.5.380-dbg/bin/ardour-3.5.380 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
bnd txt domain [gtk2_ardour3] to /opt/Ardour-3.5.380-dbg/share/locale
Ardour3.5.380 (built using 3.5-380-g2f6065b and GCC version 4.4.6)
ardour: [INFO]: Your system is configured to limit Ardour to only 4096 open files
[New Thread 0x7fffe918a700 (LWP 3837)]
ardour: [INFO]: Loading system configuration file /opt/Ardour-3.5.380-dbg/etc/ardour_system.rc
Loading user configuration file /home/kbrown/.config/ardour3/ardour.rc
Using SSE optimized routines
[New Thread 0x7fffe8989700 (LWP 3838)]
[New Thread 0x7fffe3fff700 (LWP 3839)]
[New Thread 0x7fffdbfff700 (LWP 3840)]
Cannot xinstall SIGPIPE error handler
ardour: [INFO]: Loading default ui configuration file /opt/Ardour-3.5.380-dbg/etc/ardour3_ui_default.conf
Loading user ui configuration file /home/kbrown/.config/ardour3/ardour3_ui.conf

(ardour-3.5.380:3833): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_N9Gtkmm2ext25CellRendererColorSelectorE::color after class was initialised
ardour: [INFO]: Loading ui configuration file /opt/Ardour-3.5.380-dbg/etc/ardour3_ui_dark.rc
[New Thread 0x7fffe8135800 (LWP 3841)]
[New Thread 0x7fffe80bb700 (LWP 3842)]
[New Thread 0x7fffe1d51700 (LWP 3843)]
[Thread 0x7fffe1d51700 (LWP 3843) exited]
[Thread 0x7fffe80bb700 (LWP 3842) exited]
[New Thread 0x7fffe1cd0700 (LWP 3844)]
[New Thread 0x7fffbd3c9700 (LWP 3845)]
[New Thread 0x7fffbcbc8700 (LWP 3846)]
[New Thread 0x7fffb7fff700 (LWP 3847)]
Found 1 along /home/kbrown/.config/ardour3/templates:/opt/Ardour-3.5.380-dbg/share/templates
run dialog
Announcement is: 
[Thread 0x7fffe8135800 (LWP 3841) exited]
[Thread 0x7fffbd3c9700 (LWP 3845) exited]
[Thread 0x7fffb7fff700 (LWP 3847) exited]
[New Thread 0x7fffe80bb700 (LWP 3848)]
[New Thread 0x7fffe1d51700 (LWP 3849)]
[New Thread 0x7fffd82a4700 (LWP 3850)]
[New Thread 0x7fffb7fff700 (LWP 3851)]
Scanning folders for bundled LV2s: /opt/Ardour-3.5.380-dbg/lib/LV2

(ardour-3.5.380:3833): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_N9Gtkmm2ext23CellRendererPixbufMultiE::active after class was initialised
[New Thread 0x7fffbc194700 (LWP 3852)]
[New Thread 0x7fffbc113700 (LWP 3853)]
[New Thread 0x7fffbc092700 (LWP 3854)]
[New Thread 0x7fffa40d2800 (LWP 3855)]
[New Thread 0x7fffbd3c9700 (LWP 3856)]
[Thread 0x7fffbcbc8700 (LWP 3846) exited]
*** Error in `/opt/Ardour-3.5.380-dbg/bin/ardour-3.5.380': double free or corruption (out): 0x00007fff8800b590 ***

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffbc092700 (LWP 3854)]
_int_malloc (av=0x7fff8c000020, bytes=176) at malloc.c:3489
3489	malloc.c: No such file or directory.
(gdb) thread apply all bt

Thread 21 (Thread 0x7fffbd3c9700 (LWP 3856)):
#0  0x00007fffecad6fbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff39b896f in g_poll () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff39a79f1 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#3  0x00007ffff39a736f in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#4  0x00007ffff39a77d2 in g_main_loop_run () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#5  0x00007ffff5d096af in BaseUI::main_thread (this=0x42d5390) at ../libs/pbd/base_ui.cc:80
#6  0x00007ffff5d0cfbf in sigc::bound_mem_functor0::operator() (this=0x42d5a08)
    at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#7  0x00007ffff5d0ccec in sigc::adaptor_functor >::operator() (this=0x42d5a00)
    at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251
#8  0x00007ffff5d0c6a3 in sigc::internal::slot_call0, void>::call_it (rep=0x42d59d0)
    at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#9  0x00007ffff4144542 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglibmm-2.4.so.1
#10 0x00007ffff39d49e3 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#11 0x00007fffef0c9182 in start_thread (arg=0x7fffbd3c9700) at pthread_create.c:312
#12 0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 20 (Thread 0x7fffa40d2800 (LWP 3855)):
#0  0x00007fffecad6fbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff72d5a88 in ARDOUR::Butler::thread_work (this=0x2881d40) at ../libs/ardour/butler.cc:150
#2  0x00007ffff72d5a0d in ARDOUR::Butler::_thread_work (arg=0x2881d40) at ../libs/ardour/butler.cc:134
#3  0x00007ffff5d34106 in fake_thread_start (arg=0x42d51e0) at ../libs/pbd/pthread_utils.cc:85
#4  0x00007fffef0c9182 in start_thread (arg=0x7fffa40d2800) at pthread_create.c:312
#5  0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 19 (Thread 0x7fffbc092700 (LWP 3854)):
#0  _int_malloc (av=0x7fff8c000020, bytes=176) at malloc.c:3489
#1  0x00007fffeca6c5f0 in __GI___libc_malloc (bytes=176) at malloc.c:2891
#2  0x00007fffef8059b5 in fftwf_malloc_plain () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#3  0x00007fffef8072ed in fftwf_mkplan () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#4  0x00007fffef8434d9 in fftwf_mkplan_hc2hc () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#5  0x00007fffef846bc9 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#6  0x00007fffef8436e0 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#7  0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#8  0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#9  0x00007fffef8cefb4 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#10 0x00007fffef8cf12e in fftwf_mkapiplan () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#11 0x00007fffef8d4c6b in fftwf_plan_many_r2r () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#12 0x00007fffef8d4dc9 in fftwf_plan_r2r () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#13 0x00007fffef8d4cdc in fftwf_plan_r2r_1d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#14 0x00007fff9721a641 in calf_plugins::analyzer::set_params(float, float, int, int, int, int, int, int, int, int, int, int) ()
---Type  to continue, or q  to quit---
   from /usr/lib/lv2/calf.lv2/calf.so
#15 0x00007fff9725875c in calf_plugins::equalizerNband_audio_module::params_changed() ()
   from /usr/lib/lv2/calf.lv2/calf.so
#16 0x00007fff9728e067 in calf_plugins::lv2_wrapper >::cb_run(void*, unsigned int) () from /usr/lib/lv2/calf.lv2/calf.so
#17 0x00007ffff76da3a8 in lilv_instance_run (instance=0x5d1db50, sample_count=128) at /home/harrison/a3/inst/include/lilv-0/lilv/lilv.h:1639
#18 0x00007ffff76e552b in ARDOUR::LV2Plugin::run (this=0x5cf17d0, nframes=128) at ../libs/ardour/lv2_plugin.cc:1868
#19 0x00007ffff76e4a93 in ARDOUR::LV2Plugin::connect_and_run (this=0x5cf17d0, bufs=..., in_map=..., out_map=..., nframes=128, offset=0)
    at ../libs/ardour/lv2_plugin.cc:1722
#20 0x00007ffff74e2c9a in ARDOUR::PluginInsert::connect_and_run (this=0x5cf06a0, bufs=..., nframes=128, offset=0, with_auto=false, now=0)
    at ../libs/ardour/plugin_insert.cc:399
#21 0x00007ffff74e3453 in ARDOUR::PluginInsert::run (this=0x5cf06a0, bufs=..., nframes=128) at ../libs/ardour/plugin_insert.cc:463
#22 0x00007ffff7568510 in ARDOUR::Route::process_output_buffers (this=0x5608f80, bufs=..., start_frame=0, end_frame=128, nframes=128, declick=0, 
    gain_automation_ok=false) at ../libs/ardour/route.cc:534
#23 0x00007ffff756891e in ARDOUR::Route::passthru_silence (this=0x5608f80, start_frame=0, end_frame=128, nframes=128, declick=0)
    at ../libs/ardour/route.cc:580
#24 0x00007ffff76cf8ea in ARDOUR::Track::no_roll (this=0x5608f80, nframes=128, start_frame=0, end_frame=128, session_state_changing=false)
    at ../libs/ardour/track.cc:450
#25 0x00007ffff73b1d0d in ARDOUR::Graph::process_one_route (this=0x3701a70, route=0x5608f80) at ../libs/ardour/graph.cc:561
#26 0x00007ffff73b5e75 in ARDOUR::GraphNode::process (this=0x56091b8) at ../libs/ardour/graphnode.cc:79
#27 0x00007ffff73b050b in ARDOUR::Graph::run_one (this=0x3701a70) at ../libs/ardour/graph.cc:384
#28 0x00007ffff73b068e in ARDOUR::Graph::helper_thread (this=0x3701a70) at ../libs/ardour/graph.cc:402
#29 0x00007ffff73b5299 in boost::_mfi::mf0::operator() (this=0x7fffbc091cd8, p=0x3701a70)
    at /home/harrison/a3/inst/include/boost/bind/mem_fn_template.hpp:49
#30 0x00007ffff73b4ee6 in boost::_bi::list1 >::operator(), boost::_bi::list0> (
    this=0x7fffbc091ce8, f=..., a=...) at /home/harrison/a3/inst/include/boost/bind/bind.hpp:253
#31 0x00007ffff73b4c2b in boost::_bi::bind_t, boost::_bi::list1 > >::operator()
    (this=0x7fffbc091cd8) at /home/harrison/a3/inst/include/boost/bind/bind_template.hpp:20
#32 0x00007ffff73b4849 in boost::detail::function::void_function_obj_invoker0, boost::_bi::list1 > >, void>::invoke (function_obj_ptr=...) at /home/harrison/a3/inst/include/boost/function/function_template.hpp:153
#33 0x0000000000cddc63 in boost::function0::operator() (this=0x7fffbc091cd0) at /home/harrison/a3/inst/include/boost/function/function_template.hpp:760
#34 0x00007fffe2d290a9 in ARDOUR::JACKAudioBackend::_start_process_thread (arg=0x2a92ea0) at ../libs/backends/jack/jack_audiobackend.cc:913
#35 0x00007fffef0c9182 in start_thread (arg=0x7fffbc092700) at pthread_create.c:312
#36 0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 18 (Thread 0x7fffbc113700 (LWP 3853)):
#0  0x00007fffef806d04 in fftwf_md5putc () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#1  0x00007fffef8083af in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#2  0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#3  0x00007fffef84510c in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#4  0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#5  0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#6  0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
---Type  to continue, or q  to quit---
#7  0x00007fffef843760 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#8  0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#9  0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#10 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#11 0x00007fffef846ae8 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#12 0x00007fffef8436e0 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#13 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#14 0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#15 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#16 0x00007fffef84bfc7 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#17 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#18 0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#19 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#20 0x00007fffef807405 in fftwf_mkplan_f_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#21 0x00007fffef845032 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#22 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#23 0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#24 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#25 0x00007fffef843760 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#26 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#27 0x00007fffef808658 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#28 0x00007fffef8cef00 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#29 0x00007fffef8cf12e in fftwf_mkapiplan () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#30 0x00007fffef8d4c6b in fftwf_plan_many_r2r () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#31 0x00007fffef8d4dc9 in fftwf_plan_r2r () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#32 0x00007fffef8d4cdc in fftwf_plan_r2r_1d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#33 0x00007fff9721a641 in calf_plugins::analyzer::set_params(float, float, int, int, int, int, int, int, int, int, int, int) ()
   from /usr/lib/lv2/calf.lv2/calf.so
#34 0x00007fff9725875c in calf_plugins::equalizerNband_audio_module::params_changed() ()
   from /usr/lib/lv2/calf.lv2/calf.so
#35 0x00007fff9728e067 in calf_plugins::lv2_wrapper >::cb_run(void*, unsigned int) () from /usr/lib/lv2/calf.lv2/calf.so
#36 0x00007ffff76da3a8 in lilv_instance_run (instance=0x567a840, sample_count=128) at /home/harrison/a3/inst/include/lilv-0/lilv/lilv.h:1639
#37 0x00007ffff76e552b in ARDOUR::LV2Plugin::run (this=0x564e4b0, nframes=128) at ../libs/ardour/lv2_plugin.cc:1868
#38 0x00007ffff76e4a93 in ARDOUR::LV2Plugin::connect_and_run (this=0x564e4b0, bufs=..., in_map=..., out_map=..., nframes=128, offset=0)
    at ../libs/ardour/lv2_plugin.cc:1722
#39 0x00007ffff74e2c9a in ARDOUR::PluginInsert::connect_and_run (this=0x564d390, bufs=..., nframes=128, offset=0, with_auto=false, now=0)
    at ../libs/ardour/plugin_insert.cc:399
#40 0x00007ffff74e3453 in ARDOUR::PluginInsert::run (this=0x564d390, bufs=..., nframes=128) at ../libs/ardour/plugin_insert.cc:463
#41 0x00007ffff7568510 in ARDOUR::Route::process_output_buffers (this=0x4f653b0, bufs=..., start_frame=0, end_frame=128, nframes=128, declick=0, 
    gain_automation_ok=false) at ../libs/ardour/route.cc:534
#42 0x00007ffff756891e in ARDOUR::Route::passthru_silence (this=0x4f653b0, start_frame=0, end_frame=128, nframes=128, declick=0)
    at ../libs/ardour/route.cc:580
---Type  to continue, or q  to quit---
#43 0x00007ffff76cf8ea in ARDOUR::Track::no_roll (this=0x4f653b0, nframes=128, start_frame=0, end_frame=128, session_state_changing=false)
    at ../libs/ardour/track.cc:450
#44 0x00007ffff73b1d0d in ARDOUR::Graph::process_one_route (this=0x3701a70, route=0x4f653b0) at ../libs/ardour/graph.cc:561
#45 0x00007ffff73b5e75 in ARDOUR::GraphNode::process (this=0x4f655e8) at ../libs/ardour/graphnode.cc:79
#46 0x00007ffff73b050b in ARDOUR::Graph::run_one (this=0x3701a70) at ../libs/ardour/graph.cc:384
#47 0x00007ffff73b068e in ARDOUR::Graph::helper_thread (this=0x3701a70) at ../libs/ardour/graph.cc:402
#48 0x00007ffff73b5299 in boost::_mfi::mf0::operator() (this=0x7fffbc112cd8, p=0x3701a70)
    at /home/harrison/a3/inst/include/boost/bind/mem_fn_template.hpp:49
#49 0x00007ffff73b4ee6 in boost::_bi::list1 >::operator(), boost::_bi::list0> (
    this=0x7fffbc112ce8, f=..., a=...) at /home/harrison/a3/inst/include/boost/bind/bind.hpp:253
#50 0x00007ffff73b4c2b in boost::_bi::bind_t, boost::_bi::list1 > >::operator()
    (this=0x7fffbc112cd8) at /home/harrison/a3/inst/include/boost/bind/bind_template.hpp:20
#51 0x00007ffff73b4849 in boost::detail::function::void_function_obj_invoker0, boost::_bi::list1 > >, void>::invoke (function_obj_ptr=...) at /home/harrison/a3/inst/include/boost/function/function_template.hpp:153
#52 0x0000000000cddc63 in boost::function0::operator() (this=0x7fffbc112cd0) at /home/harrison/a3/inst/include/boost/function/function_template.hpp:760
#53 0x00007fffe2d290a9 in ARDOUR::JACKAudioBackend::_start_process_thread (arg=0x2a92ea0) at ../libs/backends/jack/jack_audiobackend.cc:913
#54 0x00007fffef0c9182 in start_thread (arg=0x7fffbc113700) at pthread_create.c:312
#55 0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 17 (Thread 0x7fffbc194700 (LWP 3852)):
#0  0x00007fffecade85a in mmap64 () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffeca5d163 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7fffecb6ba10 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:147
#2  0x00007fffeca694ae in malloc_printerr (ptr=, str=0x7fffecb6bb40 "double free or corruption (out)", action=1) at malloc.c:4996
#3  _int_free (av=, p=, have_lock=0) at malloc.c:3840
#4  0x00007fffef807e53 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#5  0x00007fffef8087ec in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#6  0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#7  0x00007fffef843760 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#8  0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#9  0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#10 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#11 0x00007fffef846ae8 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#12 0x00007fffef8436e0 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#13 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#14 0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#15 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#16 0x00007fffef84bfc7 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#17 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#18 0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#19 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#20 0x00007fffef807405 in fftwf_mkplan_f_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#21 0x00007fffef845032 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
---Type  to continue, or q  to quit---
#22 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#23 0x00007fffef8085b6 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#24 0x00007fffef80736e in fftwf_mkplan_d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#25 0x00007fffef843760 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#26 0x00007fffef807697 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#27 0x00007fffef808658 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#28 0x00007fffef8cef00 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#29 0x00007fffef8cf12e in fftwf_mkapiplan () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#30 0x00007fffef8d4c6b in fftwf_plan_many_r2r () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#31 0x00007fffef8d4dc9 in fftwf_plan_r2r () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#32 0x00007fffef8d4cdc in fftwf_plan_r2r_1d () from /opt/Ardour-3.5.380-dbg/lib/libfftw3f.so.3
#33 0x00007fff9721a641 in calf_plugins::analyzer::set_params(float, float, int, int, int, int, int, int, int, int, int, int) ()
   from /usr/lib/lv2/calf.lv2/calf.so
#34 0x00007fff9725875c in calf_plugins::equalizerNband_audio_module::params_changed() ()
   from /usr/lib/lv2/calf.lv2/calf.so
#35 0x00007fff9728e067 in calf_plugins::lv2_wrapper >::cb_run(void*, unsigned int) () from /usr/lib/lv2/calf.lv2/calf.so
#36 0x00007ffff76da3a8 in lilv_instance_run (instance=0x4fd7530, sample_count=128) at /home/harrison/a3/inst/include/lilv-0/lilv/lilv.h:1639
#37 0x00007ffff76e552b in ARDOUR::LV2Plugin::run (this=0x4fab1c0, nframes=128) at ../libs/ardour/lv2_plugin.cc:1868
#38 0x00007ffff76e4a93 in ARDOUR::LV2Plugin::connect_and_run (this=0x4fab1c0, bufs=..., in_map=..., out_map=..., nframes=128, offset=0)
    at ../libs/ardour/lv2_plugin.cc:1722
#39 0x00007ffff74e2c9a in ARDOUR::PluginInsert::connect_and_run (this=0x4faa0e0, bufs=..., nframes=128, offset=0, with_auto=false, now=0)
    at ../libs/ardour/plugin_insert.cc:399
#40 0x00007ffff74e3453 in ARDOUR::PluginInsert::run (this=0x4faa0e0, bufs=..., nframes=128) at ../libs/ardour/plugin_insert.cc:463
#41 0x00007ffff7568510 in ARDOUR::Route::process_output_buffers (this=0x4f391b0, bufs=..., start_frame=0, end_frame=128, nframes=128, declick=0, 
    gain_automation_ok=false) at ../libs/ardour/route.cc:534
#42 0x00007ffff756891e in ARDOUR::Route::passthru_silence (this=0x4f391b0, start_frame=0, end_frame=128, nframes=128, declick=0)
    at ../libs/ardour/route.cc:580
#43 0x00007ffff76cf8ea in ARDOUR::Track::no_roll (this=0x4f391b0, nframes=128, start_frame=0, end_frame=128, session_state_changing=false)
    at ../libs/ardour/track.cc:450
#44 0x00007ffff73b1d0d in ARDOUR::Graph::process_one_route (this=0x3701a70, route=0x4f391b0) at ../libs/ardour/graph.cc:561
#45 0x00007ffff73b5e75 in ARDOUR::GraphNode::process (this=0x4f393e8) at ../libs/ardour/graphnode.cc:79
#46 0x00007ffff73b050b in ARDOUR::Graph::run_one (this=0x3701a70) at ../libs/ardour/graph.cc:384
#47 0x00007ffff73b0986 in ARDOUR::Graph::main_thread (this=0x3701a70) at ../libs/ardour/graph.cc:440
#48 0x00007ffff73b5299 in boost::_mfi::mf0::operator() (this=0x7fffbc193cd8, p=0x3701a70)
    at /home/harrison/a3/inst/include/boost/bind/mem_fn_template.hpp:49
#49 0x00007ffff73b4ee6 in boost::_bi::list1 >::operator(), boost::_bi::list0> (
    this=0x7fffbc193ce8, f=..., a=...) at /home/harrison/a3/inst/include/boost/bind/bind.hpp:253
#50 0x00007ffff73b4c2b in boost::_bi::bind_t, boost::_bi::list1 > >::operator()
    (this=0x7fffbc193cd8) at /home/harrison/a3/inst/include/boost/bind/bind_template.hpp:20
#51 0x00007ffff73b4849 in boost::detail::function::void_function_obj_invoker0, boost::_bi::list1 > >, void>::invoke (function_obj_ptr=...) at /home/harrison/a3/inst/include/boost/function/function_template.hpp:153
#52 0x0000000000cddc63 in boost::function0::operator() (this=0x7fffbc193cd0) at /home/harrison/a3/inst/include/boost/function/function_template.hpp:760
---Type  to continue, or q  to quit---
#53 0x00007fffe2d290a9 in ARDOUR::JACKAudioBackend::_start_process_thread (arg=0x2a92ea0) at ../libs/backends/jack/jack_audiobackend.cc:913
#54 0x00007fffef0c9182 in start_thread (arg=0x7fffbc194700) at pthread_create.c:312
#55 0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 16 (Thread 0x7fffb7fff700 (LWP 3851)):
#0  0x00007fffef0d0b9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff39d60b8 in g_usleep () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff726ddbc in ARDOUR::AudioEngine::meter_thread (this=0x1e09ad0) at ../libs/ardour/audioengine.cc:382
#3  0x00007ffff7279f2b in boost::_mfi::mf0::operator() (this=0x2a92440, p=0x1e09ad0)
    at /home/harrison/a3/inst/include/boost/bind/mem_fn_template.hpp:49
#4  0x00007ffff7279afa in boost::_bi::list1 >::operator(), boost::_bi::list0> (this=0x2a92450, f=..., a=...) at /home/harrison/a3/inst/include/boost/bind/bind.hpp:253
#5  0x00007ffff72793d3 in boost::_bi::bind_t, boost::_bi::list1 > >::operator() (this=0x2a92440) at /home/harrison/a3/inst/include/boost/bind/bind_template.hpp:20
#6  0x00007ffff7278bac in sigc::adaptor_functor, boost::_bi::list1 > > >::operator() (this=0x2a92440) at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251
#7  0x00007ffff7277ce6 in sigc::internal::slot_call0, boost::_bi::list1 > >, void>::call_it (rep=0x2a92410) at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#8  0x00007ffff4144542 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglibmm-2.4.so.1
#9  0x00007ffff39d49e3 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#10 0x00007fffef0c9182 in start_thread (arg=0x7fffb7fff700) at pthread_create.c:312
#11 0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 15 (Thread 0x7fffd82a4700 (LWP 3850)):
#0  sem_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_timedwait.S:101
#1  0x00007fffe2ac06cc in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#2  0x00007fffe2aa40f9 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007fffe2aa8bc6 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007fffe2aa27ba in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#5  0x00007fffe2aa267e in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#6  0x00007fffe2aa029e in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#7  0x00007fffe2a9bdd8 in jack_cycle_wait () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#8  0x00007fffe2d2914e in ARDOUR::JACKAudioBackend::process_thread (this=0x22268c0) at ../libs/backends/jack/jack_audiobackend.cc:935
#9  0x00007fffe2d290fe in ARDOUR::JACKAudioBackend::_process_thread (arg=0x22268c0) at ../libs/backends/jack/jack_audiobackend.cc:921
#10 0x00007fffe2aa026b in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#11 0x00007fffe2abf858 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#12 0x00007fffef0c9182 in start_thread (arg=0x7fffd82a4700) at pthread_create.c:312
#13 0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 14 (Thread 0x7fffe1d51700 (LWP 3849)):
#0  0x00007fffef0d03bd in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffe2ac1cf6 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#2  0x00007fffe2ac5287 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
---Type  to continue, or q  to quit---
#3  0x00007fffe2ac4f9c in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007fffe2abf858 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#5  0x00007fffef0c9182 in start_thread (arg=0x7fffe1d51700) at pthread_create.c:312
#6  0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 13 (Thread 0x7fffe80bb700 (LWP 3848)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fffe2ac0d5a in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#2  0x00007fffe2abcf21 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007fffe2abf858 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007fffef0c9182 in start_thread (arg=0x7fffe80bb700) at pthread_create.c:312
#5  0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 9 (Thread 0x7fffe1cd0700 (LWP 3844)):
#0  0x00007fffecad6fbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff39b896f in g_poll () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff39a79f1 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#3  0x00007ffff39a736f in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#4  0x00007ffff39a7468 in g_main_context_iteration () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#5  0x00007ffff39a8f6f in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#6  0x00007ffff39d49e3 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#7  0x00007fffef0c9182 in start_thread (arg=0x7fffe1cd0700) at pthread_create.c:312
#8  0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7fffdbfff700 (LWP 3840)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff39f939d in g_cond_wait () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff721c23b in ARDOUR::Analyser::work () at ../libs/ardour/analyser.cc:81
#3  0x00007ffff721bfd1 in analyser_work () at ../libs/ardour/analyser.cc:46
#4  0x0000000001330fd7 in sigc::pointer_functor0::operator()() const ()
#5  0x000000000132e4ea in sigc::adaptor_functor >::operator()() const ()
#6  0x000000000132ab8d in sigc::internal::slot_call0, void>::call_it (rep=0x1f82d70)
    at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#7  0x00007ffff4144542 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglibmm-2.4.so.1
#8  0x00007ffff39d49e3 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#9  0x00007fffef0c9182 in start_thread (arg=0x7fffdbfff700) at pthread_create.c:312
#10 0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7fffe3fff700 (LWP 3839)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff39f939d in g_cond_wait () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff76a6495 in peak_thread_work () at ../libs/ardour/source_factory.cc:68
#3  0x0000000001330fd7 in sigc::pointer_functor0::operator()() const ()
---Type  to continue, or q  to quit---
#4  0x000000000132e4ea in sigc::adaptor_functor >::operator()() const ()
#5  0x000000000132ab8d in sigc::internal::slot_call0, void>::call_it (rep=0x1e04d20)
    at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#6  0x00007ffff4144542 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglibmm-2.4.so.1
#7  0x00007ffff39d49e3 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#8  0x00007fffef0c9182 in start_thread (arg=0x7fffe3fff700) at pthread_create.c:312
#9  0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7fffe8989700 (LWP 3838)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff39f939d in g_cond_wait () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff76a6495 in peak_thread_work () at ../libs/ardour/source_factory.cc:68
#3  0x0000000001330fd7 in sigc::pointer_functor0::operator()() const ()
#4  0x000000000132e4ea in sigc::adaptor_functor >::operator()() const ()
#5  0x000000000132ab8d in sigc::internal::slot_call0, void>::call_it (rep=0x1f820f0)
    at /home/harrison/a3/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#6  0x00007ffff4144542 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglibmm-2.4.so.1
#7  0x00007ffff39d49e3 in ?? () from /opt/Ardour-3.5.380-dbg/lib/libglib-2.0.so.0
#8  0x00007fffef0c9182 in start_thread (arg=0x7fffe8989700) at pthread_create.c:312
#9  0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7fffe918a700 (LWP 3837)):
#0  0x00007fffecaaad7d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffecadc334 in usleep (useconds=) at ../sysdeps/unix/sysv/linux/usleep.c:32
#2  0x000000000165cef6 in gui_event_loop (ptr=0x0) at ../gtk2_ardour/linux_vst_gui_support.cc:380
#3  0x00007fffef0c9182 in start_thread (arg=0x7fffe918a700) at pthread_create.c:312
#4  0x00007fffecae430d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7ffff7fa5940 (LWP 3833)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007ffff73b1ef4 in PBD::ProcessSemaphore::wait (this=0x3701b60) at /home/harrison/ardour/3.0/libs/pbd/pbd/semutils.h:41
#2  0x00007ffff73b1aba in ARDOUR::Graph::routes_no_roll (this=0x3701a70, nframes=128, start_frame=0, end_frame=128, non_rt_pending=false, declick=0)
    at ../libs/ardour/graph.cc:543
#3  0x00007ffff7641bf1 in ARDOUR::Session::no_roll (this=0x287bba0, nframes=128) at ../libs/ardour/session_process.cc:120
#4  0x00007ffff7643e43 in ARDOUR::Session::follow_slave (this=0x287bba0, nframes=128) at ../libs/ardour/session_process.cc:612
#5  0x00007ffff7642b5e in ARDOUR::Session::process_with_events (this=0x287bba0, nframes=128) at ../libs/ardour/session_process.cc:360
#6  0x00007ffff76418aa in ARDOUR::Session::process (this=0x287bba0, nframes=128) at ../libs/ardour/session_process.cc:75
#7  0x00007ffff726de85 in ARDOUR::AudioEngine::set_session (this=0x1e09ad0, s=0x287bba0) at ../libs/ardour/audioengine.cc:404
#8  0x00007ffff75ae181 in ARDOUR::Session::Session (this=0x287bba0, eng=..., fullpath=..., snapshot_name=..., bus_profile=0x0, mix_template=...)
    at ../libs/ardour/session.cc:347
#9  0x0000000000cfe747 in ARDOUR_UI::load_session (this=0x1e632c0, path=..., snap_name=..., mix_template=...) at ../gtk2_ardour/ardour_ui.cc:2816
#10 0x0000000000cfe2ae in ARDOUR_UI::get_session_parameters (this=0x1e632c0, quit_on_cancel=false, should_be_new=false, load_template=...)
    at ../gtk2_ardour/ardour_ui.cc:2747
---Type  to continue, or q  to quit---
#11 0x0000000000cf3bd9 in ARDOUR_UI::starting (this=0x1e632c0) at ../gtk2_ardour/ardour_ui.cc:828
#12 0x00007ffff60e5599 in Gtkmm2ext::UI::run (this=0x1e632c0, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:268
#13 0x0000000001119e95 in main (argc=1, argv=0x7fffffffd0a8) at ../gtk2_ardour/main.cc:519
(gdb)
seablade
User offline. Last seen 48 min 8 sec ago. Offline
Joined: 2007-01-22
Posts:

Make sure you put this in Mantis as well (See the 'Bug Tracker' link at the top of the page. Also attach the ardour.session file as well so that a dev could download and open it and see if it replicates. All that being said, this bears the hallmarks of a crash related to a Calf plugin, specifically an issue that was discovered recently that makes the plugins not thread safe. You can find more information here...

https://community.ardour.org/node/8265

Sadly I don't know that there is anything Ardour can, or even should, do about this. The only option may be not to use multiple Calf plugins.

Seablade

seablade
User offline. Last seen 48 min 8 sec ago. Offline
Joined: 2007-01-22
Posts:

By the way, you could test if this is a Calf issue by making a backup of your session file, and then removing the Calf plugins from the XML, and see if the session loads. In this case it looks like it is likely an EQ plugin is my guess.

Seablade

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

Sadly I don't know that there is anything Ardour can, or even should, do about this. The only option may be not to use multiple Calf plugins

Unless ardour is asking a plugin to do something completely nonsensical, or just plain wrong, which seems unlikely, then it should not be doing anything to mitigate against things which amount to design errors in a plugin. It is completely possible to write plugins for ardour which work.

veda_sticks
User offline. Last seen 17 hours 19 min ago. Offline
Joined: 2011-03-11
Posts:

not using multiple calf plugins? ive said on many occasions that the calf plugins are the first choice on my projects, which means i have lots of them. Usually the 12 band eq, an exciter, bass enhancer, the anyliser sometmies the calf compressor though i prefer the invada one.

My most recent track has about 10 tracks and 3 buses with 25 plugins, alot of them calf.

and out of working on this project for a week its crashed maybe 3 times.

If i dont have problems then why are others having problems?

KX Studio 12.04
ardour 3.5.380
calf-plugins-git (regular calf plugins package also has no issues)

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

this is a perfect example of the threading problem with plugins that use libfftw. The crash is occuring because multiple threads are calling the libfftw planning routines, which are not thread safe. The plugin isn't doing anything wrong, ardour isn't doing anything wrong, this is just a problematic situation which we need to find a solution for.

the one thing i will note that is that i am a bit taken aback that the FFTW planning code is being called from a realtime context, but this is presumably a reflection of the parameter handling inside the plugin. on some level this feels quite wrong, but an appropriate design seems tricky (not impossible, just tricky).

kbrown
User offline. Last seen 24 weeks 3 days ago. Offline
Joined: 2013-11-09
Posts:

Wow. Thanks for the speedy replies guys! I'll have a look at the xml file and maybe see if I can update my calf plugins to the latest and greatest as I am using them quite a lot.

seablade
User offline. Last seen 48 min 8 sec ago. Offline
Joined: 2007-01-22
Posts:

@paul

Been thinking about LinuxDSP's points in the other thread, I think I have to agree with him. In this case I think it is the plugin's responsibility to make sure they implement this correctly, even if it means not using that library. You are correct in that normally this isn't so much of an issue, but that we are getting into a context that is a specialized use of the lib, but the plugin author has to know exactly the context they are writing for and as a result they should be testing and avoiding using such libs. Sadly I don't know if there is any options out there with comparable functionality etc. that is getting to much into the actual DSP for a math luddite like me:)

@veda_sticks

Primarily because this problem is going to show up in exceedingly intermittent ways, and depending on the exact set of circumstances might happen quite often, or almost none at all. That is the trick to managing multi-threaded processes, if one thread goes to quick it may throw off another and you get a crash, so you have to schedule everything that happens appropriately, not something always easy to do and may act different in different circumstances.

So in some cases you may luck out, in others not so much. One big difference in A3 is there is a LOT more threaded processing happening than in A2 so this wasn't as likely to show up in A2.

I will say I personally like the overall vision for the Calf plugins, and even spent some time trying to get them packaged and running on OS X as well with a fair amount of success, but the filter quality of the EQs and a couple of other issues have made me shelve that idea, just not convinced the reward for the time is there, and that there aren't better options for a good 'starting' set of plugins.

Seablade

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

I think it is the plugin's responsibility to make sure they implement this correctly, even if it means not using that library...

And if you were writing plug-ins for Mac / Windows DAWs then that is the only option you would have (and you would likely know a lot less about how the host was implementing anything ) and yet, apparently, there are quite a lot of plugins for Mac / Windows which seem to work just fine...

Meanwhile, in other news... it turns out that writing plugins is actually much more difficult than most people think.. (or in the case of linux, than it should ever have to be..) :)

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

@linuxdsp: Those plugins don't use a GPL'ed FFT library that consciously chose to eschew implicit locking.

And note: it is impossible for the plugins to do the right thing. They may be sharing the library with the host, but they cannot share the synchronization mechanism with the host. They may be sharing the library with plugins from other developers, but they cannot share the synchronization mechanism with those other plugins.

If this happened on a non-open-source platform, you'd really have no choice but to use a different FFT library.

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

Those plugins don't use a GPL'ed FFT library that consciously chose to eschew implicit locking.

If this happened on a non-open-source platform, you'd really have no choice but to use a different FFT library.

Agreed, and both of those issues are an important aspect of the plugin design (and certainly not something the host application should have to concern itself with..) I had to design my own FFT code, for many, if not all, of the reasons implicated in this discussion - and to avoid any implicit interdependency between e.g. DSP and GUI threads - which is a whole other minefield. - It was never even an option to consider anything different. The downside of engineering such a 'bespoke' solution is that, by its nature, it doesn't perhaps get as much exposure / testing as a general library might, however it can be tailored to some very specific requirements of a plugin, and tends to impose the need to acquire some working technical appreciation of the DSP code required, which is not a bad thing for any plugin developer to do.

jrigg
User offline. Last seen 7 weeks 6 days ago. Offline
Joined: 2007-01-04
Posts:

Wouldn't static linking mitigate the problem here? The current git version of Calf takes up over 40MB on amd64. Even a large FFT library like the full version of libfftw3 wouldn't really be a significant increase in size.

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

We are going to provide a "hacked" version of libfftw as part of the Ardour binary bundles as one way to address this issue.

This is sensible reading to see the libfftw position on all this stuff: http://www.fftw.org/fftw3_doc/Thread-safety.html

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

We are going to provide a "hacked" version of libfftw as part of the Ardour binary bundles as one way to address this issue.

Seriously? With the greatest respect, have you taken leave of your senses?? I hope this is only temporary, because unless there is something fundamentally wrong with ardour, it is not ardour's (or any other host's) concern to mitigate against problems in third party plug-ins, whether caused by improper use of another library or not - all this will do is mean that some plugins will work with some builds of ardour, and / or some builds of fftw, with absolutely no way of version controlling any of the resulting compatibility mess. Those plugins will still be unreliable in other host applications, or are we to assume that all plugins must be ardour specific (or ardour only? ) The worst part about this horrible hack, is that the nature of the problem is intermittent, and sporadic, so if you do happen to have the wrong mix of voodoo on your system you won't even know it immediately..

kbrown
User offline. Last seen 24 weeks 3 days ago. Offline
Joined: 2013-11-09
Posts:

While I can't really give any input on the dev side of things here, I still managed to get things working by uninstalling the packaged version of calf plugins and pulling, compiling and installing the latest git version instead. All is good for now. Thanks for the help guys!

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

Yes, the git/absolute latest release of the CALF plugins has removed their use of the FFTW planning code from the realtime threads, which removes the multithreading problem. But the basic problem still remains as a theoretical one.

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

@linuxdsp: there is no "improper use of another library". As mentioned upthread, there isn't anyway for plugins and the host to coordinate their use of a library that doesn't use implicit locking. Neither the plugins nor the host are doing anything wrong. If you want to host multiple instances of plugins that use such a library, and there is any chance that the host will cause the plugin to run code in multiple threads, then there is no "correct" solution ... unless the only correct solution you will admit to is "every plugin developer must avoid libraries X, Y and Z".

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

@paul: I completely understand the problem, but as I understand it you are not solving it the right way - if you bundle a hacked library with ardour, then that will work, if you use those plugins with that (binary) build of ardour, but if you build it from source against 'normal' fftw, surely there will be a problem, but the user won't know, until it randomly blows up (and they can't reload their work).
If you provide the hacked libraries as part of the ardour source, that might go some way to mitigate that issue, but as has happened with the other ardour specific libraries vs system libs, distributions can and will still get this wrong. But, none of that addresses the problem for other DAWs which may or may not be multithreaded and certainly won't include the custom library, in which case when used in those applications, the plugins will link against the system version of the library and still go wrong (but again, due to the intermitent nature of the problem, the user wouldn't be aware of it until something disastrous happens).
If you are going to hack the library, surely the 'correct' way is to do so in a compatible manner, if possible, and provide those changes back to the library developer? The only other solution is that the plugin developers acknowlegde the library is not fit for this particular purpose (what I meant by 'improper use of the library' e.g. using it in a way for which it wasn't designed) and build their own code - which may actually turn out to be better tailored to their plugin.

unless the only correct solution you will admit to is "every plugin developer must avoid libraries X, Y and Z"...

If those libraries are not threadsafe in a way which will allow the plugin to run in the way required by the host application, and the host application is not demanding something utterly ridiculous of the plugin, then yes that is the correct solution.

There is only one context in which it makes sense to customise ardour vs specific plugin compatibility to that extent, and in the interest of openness and support for diverse third-party plugins generally, I hope that is not the direction in which ardour is heading.

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

Ardour heads in the direction of making stuff work for users. Sometimes that involves hacks. In this case, the availability of a "correct" version of the CALF plugins (at least, a version that avoids using the FFTW planner in a context that is potentially multithreaded) might be sufficient to avoid us doing what is definitely a grotesque hack. But when grotesque hacks are needed to make stuff work for users, we do them.

I do not agree that plugins are using FFTW "in a way for which it was not designed".

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

But when grotesque hacks are needed to make stuff work for users, we do them.

As a developer, and someone who genuinely holds ardour and its developers in high esteem, that kind of adhoc, sticking plaster approach to engineering, and problem solving is deeply disappointing to hear. As a user, that would not make me feel reassured. I had thought (perhaps wrongly) that the open source community prided itself on avoiding such attitudes, and instead designing well engineered software. All of the components contributing to this particular issue are open source, so all of the tools required to fix this in a good consistent reliable way are there, but for some reason there is a nonsensical attitude not to use them. If nothing else, I hope perhaps the calf developers will be able to engineer a better solution.

anahata
anahata's picture
User offline. Last seen 2 hours 40 min ago. Offline
Joined: 2010-10-27
Posts:

@linuxdsp I don't fully understand the technical issues here (day job: I write software for embedded systems but not Linux), but can you explain what would be your ideal solution?
You give the impression that even if the CALF developers "engineer a better solution" that still wouldn't be quite enough: what else is needed?

(my solution as a user, so far, is to use Linuxdsp plugins mostly ;-) )

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

@anahata: In order of preference, the best solution would be if libfftw could be completely threadsafe - I don't know the details well enough to say if that would be possible, but perhaps there should be some communication with the libfftw developers to outline this use case. Paul obviously has a solution which he thinks would make libfftw work, even though this seems to be thought of as 'a hack' - again I don't know the details.

If that isn't possible or acceptable to the libfftw devs, then its really an issue about whether that library is appropriate for the plugin, which it seems it isn't, and in some cases you just have to write new plugin code rather than use a general library - its difficult but that's part of the job, its one of the reasons why I have over 50,000 lines of code in the average 'simple' plugin, just managing "that kind of thing", from custom X11 and GUI related stuff to necessary and complex DSP code (make no mistake, I'm not trying to say that anything I've created is just perfect or be so conceited as to guarantee it to be trouble free, but it is well tested within the limits of our resources, and it is designed from the ground up with an awareness of these kinds of issues, so I hope it provides a good solution).

What I'm concerned about, and think is wrong is arbitarily 'hacking' libfftw and including this in the ardour binary bundle - this doesn't address the issue for other host applications which use the system libs and it opens up the possibility of an unmaintainable and complex 'Mix' of the stuff that may or may not go wrong, depending upon whether ardour is built from source, downloaded pre-built, installed as part of some 'custom' audio distro etc etc - and because it is not a 'hard' fault, a user with the wrong mix of these components will not be aware of an issue until something disastrous happens.

Its important to fix the problem for users, but its important to fix it in the right way (its a tired analogy but I wouldn't want to drive a car or fly in a airplane maintained or built by anyone with the attitude that "if grotesque hacks are needed to make stuff work for users, we do them..."
And I don't want to see ardour move in the direction of only permitting the use of custom bundled plugins or ardour specific plugins which is the only case in which including some custom hack in the ardour bundle would make any technical sense.

seablade
User offline. Last seen 48 min 8 sec ago. Offline
Joined: 2007-01-22
Posts:

And in this case, I do have to say I agree with LinuxDSP.

The sad thing is that, as paul alluded to, this could be a far more widespread problem, affecting far more than Calf.

I have a lot more thoughts on the matter, but will leave it there for the time being.

t0bY
User offline. Last seen 2 weeks 5 days ago. Offline
Joined: 2012-08-14
Posts:

just a related topic from the musicians department from the ludwigsburg filmacademy. amogst my fellow students the producing software logic 12 for instance is not being taken seriously as much as cubase anymore, because of the consumer direction apple is heading. although it is a top of the line software, it is more and more smiled upon here because people believe its professional integrity is getting undermined by commercial interests. how true this is, is of course debatable... but in other words, with ardour one gets the feeling that you are dealing with genuinely crafted code considering the dev circumstances. Also the closeness to mixbus and harrison gives the ardour a sustainable face value . In my opinion, the notion of hacky code on the long term, would be a huge sell out and blow for the project regardless of where ardour is currently standing. ardour with the ,,slow and steady wins the race" project has an unique image which suggests quality and durability on the long term. I would strongly suggest to keep at it, see the subscribers as furure investors, and not sell out to a few impatient minds (no offence, honestly).

GMaq
GMaq's picture
User offline. Last seen 1 week 1 day ago. Offline
Joined: 2007-12-11
Posts:

Hmmm, this topic really could be spun out to epic proportions...

I think this is a very clear example of how 'free' software can show some vulnerability when placed in comparison with commercial counterparts. My cranium is too small to grasp the literal fullness of Paul and linuxdsp's debate however I think it is kind of obvious that when people think of 'professional' Audio production on Linux Ardour is the first place they will look. I don't want to belittle anyone's hard work but some of the FLOSS plugins out there are really not up to par with Ardour's level of achievement and something like this fftw debacle really shows that in a 'professional' versus 'free' arena sometimes you get what you pay for. I think linuxDSP and to a lesser known extent Harrison are providing the quality of work that is commensurate with where Ardour is at and are doing the necessary homework and groundwork as well as being there to mop up their own messes. As someone who is a user, distributor and who currently independently packages Ardour I would much rather have plugin developers be held to a higher and more rigid standard than Ardour shipping hacked crutch libraries to hide vulnerabilities in their plugins. In the longview this will produce better plugins of higher quality, I also think the potential for professional production credibility puts Ardour in a different paradigm than more casual 'bedroom production' offerings..

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

GMaq: the problem with the approach you outline is that there is really only one way to "hold plugin developers to a more rigid standard" and that is to prevent them from using the most tested, fastest, most reliable, overwhelming common FFT library in world.

I don't consider such an approach to be in anyone's interests.

t0bY
User offline. Last seen 2 weeks 5 days ago. Offline
Joined: 2012-08-14
Posts:

although i'm risking to turn into mr. smartypants here.. i think its not about preventing people from using the fft library but motivating them to choose otherwise. what if the dev team gave out some sort of certificate to plugins that are ,ardour compatible'?
my thought was that plugin developers could use it to advertise their products an give their costumers more confidence in their products. In the end this would also be a measure to spread common knowledge about certain quality standards. as gmaq said, ardour is practically out of competition with other daws on linux, so why not let requirements be heard at this point?

paul
paul's picture
User is online Online
Joined: 2006-03-16
Posts:

I think this misses the point. Other than this issue, we want people to (a) all the use the same FFT library (b) use fftw.

t0bY
User offline. Last seen 2 weeks 5 days ago. Offline
Joined: 2012-08-14
Posts:

ok, sry for mixing things up..

linuxdsp
linuxdsp's picture
User offline. Last seen 3 weeks 2 hours ago. Offline
Joined: 2009-02-04
Posts:

@t0by:

what if the dev team gave out some sort of certificate to plugins that are ,ardour compatible'?

In a very real sense, that is exactly what I'm hoping wouldn't happen - its not that I object to the idea of giving users that confidence, but, because it sets out a framework / potential roadmap for 'Ardour specific' plugins - and that's at the root of the reason why I disagree with Paul's proposed method for solving this particular issue. I actually agree with (a) and (b) in Paul's reply, but I think we disagree on the implementation of it. The whole point of my argument is that by including an ardour specific fftw, if we're covinced that really is the issue with these plugins, then it inherently makes those plugins ardour-only (and ardour binary only)
As a developer I want to see a diverse range of plugins, and I want users to have compatibility (within the - slightly loose - definition of current linux plugin standards) with as many hosts as possible. When you buy / build / download a plugin you should be able to use that on any 'compatible' host - not only on some or other with the right libraries or the right LV2 extensions or the right mix of this or that - that's exactly the kind of 'walled garden' approach people object to about other platforms (its just that on linux it often happens through lack of design competence rather than for deliberate commercial advantage)

We need to move to a more inclusive approach, not one which encourages segregation by design choices - if linux audio is ever to be more than a very small minority pursuit and if there is to be broader interest from a wide range of developers (which in the end is sustainably of benefit to users)

In my opinion LV2 is already in danger of being co-opted as a convenient means of lock-in on other operating systems by at least one well known commercial developer - most likely as an accidental but commercially useful advantage of its lack of adoption on those platforms, but I don't want to see that kind of thing or anything like it happen (for commercial benefit or just by accident of bad design choices) on linux.