Ardour crash in clone() with custom-compiled ardour

Hello

I recently tried to build ardour from git.
It builds successfully, on debian 8.0, and runs flawlessly on my machine.

With a friend, we worked together on a project, with ardour version git-295a7dfcf3acf664046ca5331555647ddd4b0dbc

When my friend launches my custom compiled version on ubuntu 14 (trusty), he is able to create a new session.
But when he loads a project, ardour crashes with this backtrace (using dummy output):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd0028d80 (LWP 16902)]
0x00007ffff69cd3a7 in ARDOUR::AudioBuffer::read_from(ARDOUR::Buffer const&, long, long, long) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
(gdb) bt
#0  0x00007ffff69cd3a7 in ARDOUR::AudioBuffer::read_from(ARDOUR::Buffer const&, long, long, long) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#1  0x00007ffff6a72470 in ARDOUR::Delivery::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#2  0x00007ffff6dcfea2 in ARDOUR::Send::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#3  0x00007ffff6da07a9 in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, int, bool) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#4  0x00007ffff6d9c82a in ARDOUR::Route::passthru(ARDOUR::BufferSet&, long, long, unsigned int, int) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#5  0x00007ffff6d9fe9f in ARDOUR::Route::no_roll(unsigned int, long, long, bool) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#6  0x00007ffff6b291c7 in ARDOUR::Graph::process_one_route(ARDOUR::Route*) () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#7  0x00007ffff6b28ec0 in ARDOUR::Graph::run_one() () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#8  0x00007ffff6b29781 in ARDOUR::Graph::main_thread() () from /tmp/Ardour_x86_64-5.4.31/lib/libardour.so.3
#9  0x00007fffd33aa9e6 in ARDOUR::DummyAudioBackend::dummy_process_thread(void*) () from /tmp/Ardour_x86_64-5.4.31/lib/backends/libdummy_audiobackend.so
#10 0x00007ffff0cc0184 in start_thread (arg=0x7fffd0028d80) at pthread_create.c:312
#11 0x00007fffedab737d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

He is able to open the 6 first versions of the project, but when he tries to open anything greater or equal to version 7, ardour crashes.

My first completely unscientific thought is, are the versions of glibc the same between those two distributions?

 Seablade

Both are using libc-2.19.so. But I had to bundle libstdc++ from my build machine, otherwise I was having these error:

/tmp/Ardour_x86_64-5.4.31/bin/ardour-5.4.31: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/Ardour_x86_64-5.4.31/bin/ardour-5.4.31)
...
/tmp/Ardour_x86_64-5.4.31/bin/ardour-5.4.31: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/Ardour_x86_64-5.4.31/lib/libglibmm-2.4.so.1)
/tmp/Ardour_x86_64-5.4.31/bin/ardour-5.4.31: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/Ardour_x86_64-5.4.31/lib/libtag.so.1)
/tmp/Ardour_x86_64-5.4.31/bin/ardour-5.4.31: /lib/x86_64-linux-gnu/libkeyutils.so.1: version `KEYUTILS_1.5' not found (required by /tmp/Ardour_x86_64-5.4.31/lib/libkrb5.so.3)

Do you know what is done to prevents these kinds of libraries versions mismatch, in official ardour build?
Thank you

We do not support self-compiled versions of Ardour. If you can reproduce the issue with a build from ardour.org, please file a bug. Bug reports do not belong on the forums - they will be ignored/forgotten.

Hi
We decided to give ardour a try, for different reasons.
These 3 major points made us really try to switch from ableton live to ardour:

  • it runs on linux
  • it is open source
  • other features like osc, lua scripting …

We understand that ardour needs some funding, and we are ready to give money to support this project.

But we need to be sure that if we create a project now, we will be able to open it in a few years, even if we have to compile lots of software or run an outdated OS.

The whole point of ardour being open source is useless, if we cannot build it ourselves.

I do not ask you to support my custom build, but I would like a way to ensure that I can build and run a same binary and run it on different linux distros.

What if some day, you decide to stop providing daily builds, or to increase the price of the next major version, for instance?
I simply would like to increase my ‘trust’ in ardour, by being able to build it myself.

Thank you
Eric

@cyberic

Did you try building a copy on Debian instead of just running the Ubuntu copy on Debian? The redistribution of the software is the tricky part, for reasons similar to what I mentioned above, the building of it as you hopefully already saw, at least on Linux, isn’t to difficult. Mac and Windows, those are a different story:)

  Seablade

I’m also concerned about will I be able to open my projects in the future and that is one of the main reasons I swithced from Pro Tools to Ardour. A commercial program forces you to constantly upgrade your OS and hardware and while doing that constantly pay for the priviledge of having a working / current system. A open source project won’t force you to do this. But if you need to be able to open your projects in say 5 - 10 years time, there are more things to consider.

You probably cannot build a old version of Ardour on a new operating system in 5 years time, since the old library versions that the old Ardour requires will not be there. You may still be able to install the official version of Ardour though, since it includes some of the libraries it depends on. I think you should stick with the official build of Ardrour and backup the installers for future use.

Software (including libraries) is constantly moving forward and breaking compatibility with older versions of it itself. There is no way one can protect oneself from this force of change in software. You can keep an old computer around with an old OS, but hardware won’t last either. The capacitors on main boards have a limited life span. If you are good with a soldering iron, you can prolong the life of a machine periodically changing caps to new ones in the hardware and power supply.

A open source project is still the best bet if you want to future proof your sessions, because it does not have a financial need to keep you buying new versions of the software, upgrade OS and hardware. I can still use Ardour 3 on a current OS if I want to.

I have found that the only real thing that completely future proofs one is exporting each important session as stem mixes, each audio component in its own file (drum, guitars, voice, bass, etc, one file per instrument / component). You will be able to open these in any future audio editor you may use. I’ve been using multitrack editors since late 90’s and I have stuff made with: Cooledit Pro, Saw+, Samplitude, Cakewalk, Pro Tools, Logic Studio and now Ardour. If you ever decide to change your multitrack editor, the only way to migrate your stuff forward is exporting stem mixes.

The issue with self-builds is that you almost certainly do not use precisely the same versions of the dependency stack that Ardour relies on. We document that stack and versions being used (updated daily on the nightly site). Since the versions of the various parts of the dependency stack matter (sometimes they matter a LOT), it isn’t realistic for us to respond to bug reports that aren’t reproducable with official builds.

I’m absolutely not asking you to stop using your own build - you’re the only person in a position to judge if that makes sense. I’m just saying that bug reports based on a self-build are not going to result in anything useful for anyone. I hope this is clearer.

Thank you everyone for your replies.
mhartzel, you’re right about the constant software evolution.
But with today’s technologies such as virtualisation, or with docker, you can still run an outdated distribution on a current computer.
You have to keep a mirror of all the sources if they happen to vanish in the future, of course.
I’m currently trying to build most of the dependencies according to the versions found in the build info file.

What is strange, and frustrating, is that my build runs correctly on one distro, but not on another, and only on a specific project.
And that it fails in clone()

So I was wondering if any of you had a clue about what lib or lib version could be the culprit.
I will keep trying and try to reproduce a build system as close as I can from the official build env.

Thank you for your replies.
Eric

Just to give some news, I was able, after much effort, to compile a version of Ardour which can run on different linux distro.
I had to compile lots of dependencies (all the deps listed on the website, on the daily build page) with an old glibc.

And I HAD to use the patched versions of GTK and Cairo.
These were the culprit libs causing the crashes, even if the stack trace were not related.

The ‘fully relocatable’ version of GTK is required in order to build a portable bundle.

FWIW the crash is in AudioBuffer::read_from() (not clone()) and was likely fixed in 5.4-450-gfa642e0 – but it’s hard to say.

You mention building 295a7df (aka 5.0-pre0-486-g295a7df) but the backtrace says Ardour_x86_64-5.4.31 - also that backtrace does not include line-numbers. It’s confusing. http://nightly.ardour.org offers gratis debug builds and backtraces from those are usually more useful (and also a good 2nd opinion).

PS. Software that depends on shared libraries cannot simply be copied to other machines. The shared libs need to be ABI (binary) compatible. Binaries from ardour.org include all dependent libs for that purpose, which - as you found out for GTK - requires quite a bit of customization for some libs.

PPS. tracker.ardour.org is more appropriate to post backtraces and keep track of bugs.

@x42: The crash in AudioBuffer was happening only on my friend’s computer. I could run the exact same code, and open the exact same project, and I didn’t get the crash. We even compared the versions of each shared library we had, and even with that, I couldn’t reproduce the crash.
I even installed the same distribution as him, and still couldn’t reproduce it.
I finally fixed the crash as soon as I used the patched cairo and gtk versions.
I first reported the crashed here, and not on the bugtracker, because I knew that custom builds were unsupported…
In fact, I didn’t use the nightlies, because I wanted to be sure that I could rebuild my own version of ardour, even in several years. (see the discussion in previous posts).