Ardour segfaults 9/10 times when opening my favorite project. JACK, Demons or LADSPA plugins?

Hello community! I am running Ardour 3.5.403 on JACK on Linux Mint. I was going to post a quick bug report here, but since I can’t explain exactly how to reproduce this problem, I feel that it’s better to tell you a story and then maybe we can solve this mystery together. Any help is appreciated.

I am a humble bedroom producer, but sometime I push Ardour to its extremes. I work with lots of tracks, hour-long audio files, tall chains of plugins, and I even use Ardour as sort of an ERSATZ drum editor by duplicating one hit 100s of times. Naturally, I expect Ardour to occasionally crash. That said, I don’t feel I deserve what is happening to me now.

I am working on a really fun Drum & Bass track. It’s got a dirty bassline, a cool synth melody, and my friend even let me borrow his analog VCO to lay down some textural effects. About halfway through the project I decided that this would be some of my best work.

Then, the segfaults came.

At first, they were business as usual. I would press ctrl+Z too many times, or delete a MIDI note too quickly, Ardour would crash, and I would cheerfully restart it having lost only five minutes of work. Then, it got worse. Ardour would segfault every time I tried to open my project until eventually the only way I could open it was by opening ANOTHER project, THEN opening the DnB project.

Now, not even that seems to work. Every time I open the project, here is a play by play:

  1. The project and interface loads but is unresponsive
  2. The little asterisk up on the window bar indicating whether the project has unsaved changes blinks on and off for serveral seconds
  3. Ardour disappears.

Weirder still are the error messages. They are different every time. Sometimes the console output is this:

*** Error in `/opt/Ardour-3.5.403-dbg/bin/ardour-3.5.403': double free or corruption (!prev): 0x00007fe6c400d8d0 *** Aborted
Other times, it's this:
fftw: planner.c:261: assertion failed: SLVNDX(slot) == slvndx Aborted
But most of the time, it's this:
Segmentation fault
Please let me know if you'd like to see the entire output.

Update: After about the twelfth atempt, my project has loaded successfully. Ardour seems to have eaten my MIDI regions and all my track/bus automation is missing, but it’s up and it plays. I don’t know what I did differently that would cause this, but now I am too afraid to close the project again.

Can anyone tell me how I can fix this? I’m happy to provide more details upon request. Thanks!

See this thread:
It seems there are known issues with the current version of Ardour and MIDI.
Judging from what’s reported in that thread, you might be able to rescue your project by downloading a current nightly build of Ardour and opening your project with that. If that works, save it (maybe make a copy of the entire project directory tree first) and see if you can open it with 3.5.403 again. Alternatively continue working with the nightly snapshot version of Ardour, but I don’t think that would be recommended.

Thank you for your suggestion, Anahata!

Unfortunately I have already tried a nightly build and it did not succeed in opening my main project without crashing. It did, however, open another project that had been crashing before (I should have mentioned that my case was not limited to one project) so stability seems to have improved? In any case I am excited for the new version which looks really nice. If it crashes 50% less that will be a marked improvement.

These segfaults occur in both in projects with MIDI tracks and without MIDI tracks, so I’m not convinced that the issue is solely with the current MIDI system. They seem to obey Murphy’s law quite consistently however; affecting only projects with lengthy regions or more than ten tracks, i.e., any project I’ve worked hard on. My workstation has 32 GB of RAM, an i7 processor and a very stable, boring desktop environment (Linux Mint MATE) so I doubt the issue is with my platform either.

I will continue saving snapshots of my project for as long as it is open, but I’m scared. I have not shut down my computer for days for fear that my project will never re-open again. I’m scared that the new version will not fix this issue.

Are there any other factors I may have overlooked? Any settings in JACK which may cause instability? I only recently learned that LV2 was a successor to LADSPA, so could it be some older, buggier Calf Plugins? Does the blinking “unsaved changes asterisk” offer any clues? Please help, anyone- and as always, thanks in advance.

The “double free / fftw” segfault is a plugin problem (not ardour).

The problem is: one can only run one fftw plan at a given time. On session open with plugins using fftw will often do that in parallel (as opposed to adding plugins later, usually one plugin at a time).

The issue is understood: and underway to be fixed

Some plugins (e.g. calf) have worked around this issue, and others (KXStudio) provide plugin binaries that already include a fixed fftw or workaround (static link). But as far as I know, no generic distros have picked up on that yet.

Meanwhile, you can (A) not use the plugins in question. and/or (B) update the plugins or built them yourself. To remedy the current situation and load your session. Simply remove the offending plugins from your system.
(You can also start ardour --disable-plugins or edit the .ardour session file… many roads lead to Rome)

As for midi-related crashes. Ardour 3.5.403 had countless issues that have been or are currently being resolved.
since around Ardour 3.5.4000 things have become pretty solid. see

That is very helpful to learn, x42!

It might also help explain why some of my projects in LMMS would also crash upon opening. Those projects used LADSPA plugins as well. Just about all of the LADSPA plugins I’m using have LV2 equivalents installed. Do you think replacing those plugins would make any difference?

I’m going to try your advice as soon as my next crash happens. Thanks!

@Worldsday The issue x42 mentions is not LADSPA vs LV2, it is certain plugins, be they LADSPA or LV2, though the Calf LV2 were the most notorious for a while, will suffer from this issue that will be intermittent.


@worldsday: it’s not a LADSPA vs LV2 issue.

In this case its a “plugins using fftw issue” which can be of any type (LADSPA, VST, AU, LV2,…).

Plugins that operate on the signal-spectrum, phase, some [graphical] EQs etc often use which is amazing library - except for the concurrency issue (which is well documented on

Since plugins don’t know about each other, they cannot safely use a shared (system-wide) libfftw.
The issue has been around for a while, but only became a real problem with multi-core CPUs becoming more widespread. As with all concurrency issues, there’s a bit of [bad] luck involved. It can work sometimes and sometimes not.

using LV2 instead of LADSPA can help in cases where the LADSPA is unmaintained and the LV2 developer took special precautions to mitigate the issue.

In this case its a "plugins using fftw issue" which can be of any type (LADSPA, VST, AU, LV2,...)
I think its worth emphasising again "plugins using fftw" Which is probably very few outside of the open-source community, and likely almost no commercial plug-ins - and (as a commercial developer) certainly none I've been involved in / with. (lest people should think that anything with an FFT is going to cause them problems)

Thanks, Everyone!

I just eliminated this error by taking x42’s advice, editing the project xml file and deactivating all the plugins! It worked!

Of course, now all my tracks are dry. How can I reinstate these pluigins without incurring fftw issues? I’m using mostly Calf and Invada plugins; are there any other linux audio plugin packages that I should look into that will not cause this issue? Will the issue ever be fixed in libfftw?

I use TAP-, CAPS (C*)-, and Invada-Plugins most of the time and never had issues like this.

PS: Except for the Invada-Reverb, which crashes regularly.

@linuxdsp: quite right. Even more specific: The problem only exists for plugins that dynamically link against libfftw.
This is pretty much only true for GNU/Linux distro provided ones (and maybe a few on OSX homebrew/port/fink/…).

Commercial binary or proprietary plugins that use libfftw would statically link against it (and hence have the planner in private memory space and can circumvent the issue).
This approach is currently also taken by various pro-audio distros such as KXStudio to work around while upstream works on the issue.

I checked Sourceforge and it appears that the Calf devs were aware of this issue and have migrated away from fftw. This seemed promising, so I downloaded the latest package and compiled it.
It works! All the new Calf plugins do not appear to cause segfaults. I’m thrilled! Thank you so much for helping me solve this issue, everyone!