Right, and I believe most of the messages we’re looking for are sent from the constructor. So that’s my theory on why we’re not seeing them. The constructor is most certainly being called, so the question then is why are there no debug messages coming out. Has to be crashing before they can get sent to the stream.
Meh, my memory is getting bad. Very little in the constructor for the Contour stuff. Most in the acquire device method, but we don’t see any of those messages either, which is even more confusing.
I know I’m just throwing darts in the dark, but hoping something will trigger something with you, Paul, that solves it.
Putting it on Mantis, preventing it’s being forgotten and hopefully been fixed.
Mantis report
If there’s someone who could explain me how to generate this -D XXXX flags output, Paul is asking for,
I would be more then happy to do that.
It was shown in an earlier post. When you start ardour add the text after the ardour command and capture the text output on the console
ardour9 -D contourdesigncontrol
Hey Lauren,
Biggest issue I have, and I believe the same with Paul and team, is that we don’t have a ShuttlePro2 available to test with so we can’t recreate the crash to see where it occurs. The output you’ve provided is difficult to pinpoint exactly where in the code it crashes.
I have another off the wall thought if you want to try it. I was wondering what would happen if you plugged the shuttle pro in after opening the shuttle pro configuration screen, which you can get to if you run ardour and open it up with it unplugged. So this would be the steps:
- Unplug the shuttle pro from the system
- Run ardour
- Open the Options->Surfaces page
- Activate the Shuttle Pro 2 in the device list
- Click on the Settings button to open the configuration window.
- Now plug the Shuttle Pro 2 in and see if ardour discovers it and you can configure it safely, or if ardour just crashes again.
If that works and ardour doesn’t crash, then I think crash is in the ControlSurfacesOptions constructor (see second idea below) and it’s trying to display the device data before the device is ready and the pointer is valid.
If not, then it’s on to the next theory.
It sounds like you’ve been digging into the programming challenge here. GDB has the ability to step through the code one line at a time so you can discover exactly where the program crashes. You can set break points that stop the program’s execution when it hits that point in the code, and then you can step through one line at a time until the program generates the exception that causes the crash. You can look at the attribute values and see what might be causing the crash, like finding the null pointer. Unfortunately, it’s been decades since I worked with GBD and I don’t remember how to do all that, so I can’t help much there, but I know GDB can do it, so it might be something you can explore if you’re up for it. There are plenty of resources out there to help.
If you get this far, I would recommend setting a break point in the ControlSurfacesOptions constructor in the gtk2_ardour/rc_options_editor.cc file. Should definitely get a break here. Would be good to know if it crashes here. The test above is trying to test if it does.
After that, I’d set break points in the first line of the ContourDesignControlProtocol constructor and the first line in the aquire_device method. You can find those routines in the …/Ardour-9.7.0/libs/surfaces/contourdesign/countourdesign.cc file. This is where the debug messages that we’ve been looking for should be coming from, but we never see them. It still could be crashing somewhere in those routines.
What I kind of think is happening here is that the ControlSurfaceOptions constructor will be called before the acquire_device method is called for the ShuttlePro, which I believe will cause the program to crash because the acquire_device method hasn’t finished setting up the device and a valid pointer to it. The test I mentioned above should confirm this, but I’m not sure if the device discovery will happen with the settings page open, in which case the test will fail, and that would mean we’d have to then move to the debugger to see exactly what’s going on.
And if none of this proves worth anything, on to the next theory.
Good luck.
Hello Mark,
Thank you for your idea and extensive support !
I did several tests following your steps, with consistent ( the same ) result each time.
- unplug shuttle pro2 ( this shouldn’t be nessesairy, but for testing I happy to do so )
- start ardour ( 9.7.90 )
- edit > prefs > control surfaces
- ( & 5) I can click the shuttlepro2 checkbox and access the control protocol settings window, via the active surfaces settings button, as often as I want, without Ardour crashing, so far so good.
- When now pluging in the shuttlepro2, it isnt recognized.
In the control protocol settings window : device not working, no such device ( it may have been disconnected ) notification.
If I click on the still checked shuttlepro2 checkbox to first uncheck it, and again click it to check it, the shuttle pro is found and working like it should !
Again so far so good.
Now comes the weird, unexpected but consistent step :
It’s possible to to this 1 time, if I again ( with the shuttle pro2 still connected ) deactivate the checkbox, ardour still fine, but as soon as I click TO ACTIVATE the shuttlepro2 a SECOND time, Ardour crashes.
I did repeat this process several times, each time with the result as described above.
I’m hoping you, Paul or someone else can use this detailed info to troubleshoot whats going on.
I did add this info in the Mantis report.
Kind Regards.
Hi Lauren,
Wait, so by adding that extra step, you were able to configure it and use it like you want to? That’s what I was hoping for, not that this would fix the problem; that still exists, but that you’d have a workaround that lets you use it as you want to. Just follow that process, set it up and then don’t mess with it again, or at least if you need to, just follow that process to make your changes. If you start activating and deactivating it, it will probably eventually crash at some point, though knowing it did gives some data.
And if that’s true, then I think that validates my theory. The second time you activated the device, Ardour was still holding a valid pointer to the object so it was able to activate it safely. Unfortunately, fixing the problem for good might take a while. Keep in mind that I’m just a user like you, so I don’t tell Paul what to do. 
It should really be confirmed somehow before proceeding on that drastic a measure, and there are some easy ways of fixing thread collisions like this and more detailed architectural solutions, and would be up to the team how to proceed. It would be good if there was another report of a controller surface crashing Ardour, but I’m not sure if that’s been reported. It seems like it’s just a timing issue between the threads accessing the device.
So I hope that gets your studio functioning how you want it to, at least until a more proper fix can be implemented.
Dear Paul, Mark, Robin,
I did notice, until recently I did build Ardour with non-debug option during build proces.
Today I did the new build ( 9.7.113 ) without the --optimize at ./waf configure --prefix=/usr
So I did build the most recent version with debug enabled, right ?
After building in the ardour/gtk2_ardour map I did open the konsole and type :
- ./ardbg
- ( gdb ) run -D controlproto,contourdesign
- in ardours > prefs > control surfaces > shuttlepro2 > click on checkbox so ardour crashes
- in konsole type : thread apply all bt
- followed by : c and enter to see all pages.
- I did copy this konsole output and paste it into pastebin : Ardour9.7.113-ShuttlePro2-issue
This time, as you will see, the report is different.
Does this provide the nessesairy Ardour/shuttle-pro2 bug information ?
Kind regards, Luc ( Lauren ).
The stuff I’m interested is the -D output from Ardour, not so much the backtrace from inside ./ardbg … there should have been a bunch of output before it crashed.
Sorry for the long delay (browser tab stacks 
hello Paul,
It’s getting a long forum post over here, isn’t it, and I’m out of options.
I did read the debugging Ardour on Ardours website but this doesn’t clear things up.
It seems that there’s something I don’t understand about generating the -D output from Ardour.
Thats the reason I did describe my steps in the post here above.
Please : would it be possible to explain what I’m doing wrong, or sum up in a simple few steps how to generate Ardours -D output for debugging ContourDesign Shuttle pro2 crash ( yes, a how to for dummies ok ) ?
That would be very helpfull, without asking further of your precious time.
I would be very happy to generate a debugging report, for solving this issue.
Thank You !
- be absolutely certain you have a debug build
- run it from a terminal, redirecting all the output into a file
/path/to/Ardour -D blah,bleh,bloh > /tmp/ardour.out 2>&1
- make the output file available
Ardour 9.7.113 debug build on Debian 13
- open konsole and type : /usr/bin/ardour9 -D controlproto,contourdesign
- When Ardour has loaded, I did press each button on the Contour Design ShuttlePro2,
so in the crash log you can see the output from the Shuttle. - In Ardours > prefs > control surf > click Shuttle PRO v2 check box > Ardour crashes.
- Output from console to pastebin : ArdourShuttleP2-Debug - Pastebin.com
There isn’t any ardour log or ardour.out file, neither on my system or in the tmp folder ;
but in var > lib > systemd > coredump > there is a core.ArdourGUI.1000.d8fad…zst file big 40Mb.
Don’t know if this information is any usefull.
If this is literally what you typed:
Then you did not follow Paul’s instructions where he showed how to capture the output into the ardour.out file:
> /tmp/ardour.out 2>&1
In a shell (terminal emulator like konsole) the “>” character means redirect the standard output to a file, /tmp/ardour.out is the file name (could be anything, that is just the example Paul gave), and the section “2>&1” means that the standard error output should be redirected to the standard text output so that both standard output and error output are in the same file.
Hello Chris,
Thank you for explaining, I appreciate it !
Output with : /usr/bin/ardour9 -D controlproto,contourdesign> /tmp/ardour.out 2>&1
Generates indeed a file on disk, but it looks the same to me.