Hi. Something of a newbie here, so apologies if this has come up before and I’ve not found it.
I have a project which includes a couple of tempo changes. Initially this seemed OK, but Ardour now crashes consistently whenever it reaches a change. I can neither play the session nor export audio. It crashes at the same point every time. I have sent the problem report to the developers, but I was wondering if anyone else had come across a similar problem and had any idea how (or if) it could be solved or worked around.
Originally, it was the version from the Ubuntu Studio 20.04 LTS distro. I’ve then tried upgrading to Ardour 6 via the backport that they’ve provided. It’s Ardour 6.0.0~ds0 “The Pearl” (rev 6.0.0~ds0-3~ubuntu20.04.2).
I will have a look at downloading directly from Ardour.org, though.
For what it’s worth, I have a few tempo markers in there (it’s a lockdown virtual choir thing, so I built in a rallentando) and it seemed to be OK for a while, but it now crashes when it hits the first tempo marker. I’m thinking of just removing all of the markers now, since everything is in audio at this point.
OK. Just tried the 6.2 demo version. Same thing, I’m afraid. It dies as soon as it hits the first tempo marker. It may freeze for a few seconds before dying, or just bail immediately.
I don’t pretend to understand anything about the crash report, but if it helps in any way, the title is “ardour-6.2.0 crashed with SIGSEGV in ARDOUR::Amp::apply_simple_gain()”
Oh. I see. Fair enough. I just clicked on the “Send” button on the crash report, so it makes sense it would have gone to Ubuntu, rather than you. As requested by Seablade, though, I’ll attempt to recreate it in a new session without audio and create a bug report if I manage to provoke the problem again.
In the mean time, since I don’t need the MIDI part of the project at this point, I’ve removed the tempo markers and have successfully exported.
Just so you know, this isn’t something I do a lot of or can dedicate a lot of time to (very much a hobby for a bit of fun), so I might not succeed in reproducing the problem in another session or it might take me a while.
Many thanks for looking at this, though, and I will try to come up with something I can put on a proper bug report for you.
That is understood, it is just without a reproducible test case we can’t find the problem. The other thing that can help is to use a debug build and submit the stack trace from the crash, but that can be a bit more involved, see here for more info:
But even the stack trace by itself isn’t much good if it can’t be reproduced.
Sure. Make complete sense and I do understand. The backtrace instructions seemed simple enough, so I’ve done that and will attach it to the issue. I’ll try to reproduce the problem in a new project without audio for you, then add that if I can come up with something that falls over consistently.