Custom MIDI Controller Not Showing Up on Controller List

Installation & Configuration Linux
#69

I’m sorry :

[New Thread 0x7fffbffff6c0 (LWP 4639)]
ardour-9.7.56: …/…/libusb/os/threads_posix.h:46: usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) ==
0’ failed.
Thread 1 “ArdourGUI” received signal SIGABRT, Aborted.
0x00007ffff4db095c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) thread apply all bt
Thread 94 (Thread 0x7fffbffff6c0 (LWP 4639) “pool-5”):
#0 0x00007ffff4e2a7b9 in syscall () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5d36670 in g_cond_wait_until () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff5ccc753 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff5cccd85 in g_async_queue_timeout_pop () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff5d36f0d in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff5d368c3 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#7 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 93 (Thread 0x7fffd49046c0 (LWP 4638) “pool-4”):
#0 0x00007ffff4e2a7b9 in syscall () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5d36670 in g_cond_wait_until () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff5ccc753 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff5cccd85 in g_async_queue_timeout_pop () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff5d36f0d in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff5d368c3 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#7 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 92 (Thread 0x7ffe827fc6c0 (LWP 4576) “AutomationWatch”):
#0 0x00007ffff4db69ee in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff4dab668 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff4df7fba in clock_nanosleep () at /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff4e033d3 in nanosleep () at /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff5d37f97 in g_usleep () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff71d7dc5 in ARDOUR::AutomationWatch::thread() () at /home/username/workspace/ardour
build/libs/ardour/libardour.so.3
#6 0x00007ffff6933b6f in PBD::thread::_run(void*) () at /home/username/workspace/ardour/build/libs/pbd
libpbd.so.4
#7 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#8 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 91 (Thread 0x7ffe82ffd6c0 (LWP 4575) “AutoConnect”):
#0 0x00007ffff4db69ee in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff4dab668 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff4dabc8c in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff4dae158 in pthread_cond_wait () at /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff7633a90 in ARDOUR::Session::auto_connect_thread_run() () at /home/username/workspace
ardour/build/libs/ardour/libardour.so.3
#5 0x00007ffff7633af9 in ARDOUR::Session::auto_connect_thread(void*) () at /home/username/workspace
ardour/build/libs/ardour/libardour.so.3#6 0x00007ffff6933ad0 in fake_thread_start(void*) () at /home/username/workspace/ardour/build/libs/pbd
libpbd.so.4
#7 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#8 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 90 (Thread 0x7ffe837fe6c0 (LWP 4574) “SessionSignals”):
#0 0x00007ffff4db69ee in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff4dab668 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff4dabc8c in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff4dae158 in pthread_cond_wait () at /lib/x86_64-linux-gnu/libc.so.6
–Type for more, q to quit, c to continue without paging–

#70

There’s many more pages than that … might be wise to use a paste site such as pastebin.com

#71

Hopefully this time better ( sorry Paul, but this debugging report is something I have to learn ).
I’m probably looking ‘not that smart’ over here :slight_smile:

#72

I think you’re going to need to run with -D controlproto,contourdesign from the command line.

The crash is inside libusb as Ardour tries to release it’s “handle” on the shuttlepro.

NOTE: this requires a debug build.

#73

Thanks, Lauren. Paul looks like he’s on it and I don’t think I can add any more value. Good luck! Hope a solution comes soon.

#74

The Ardour adventure is keeping me up late at night over here, still learning a lot… :slight_smile:
I just want to say : thank you for fast reply’ing and all the effort from both of you ( and probably other people involved ).
Would be so nice to see this one solved, I have no doubt that this will happen in the future.
Again : thank you !

#75

Hello Paul,

Here the GDB crash debug report with : run -D controlproto,contourdesign

https://pastebin.com/Lb6NSAbB

Hoping this is usefull for solving the shuttlepro2 crash.

#76

Alas, this has none of the output from the -D XXXX flags …

#77

Yeah, unfortunately that leaves us where we were several posts back. Feels like there’s something in the redesign that is referencing the controller before it’s ready. Any multi-threading going on here that one thread may try to reference the controller before the other thread has finished initializing it?

#78

Sorry but all this debugging is new territory for me.
It seems that I failed in giving to nessesairy information, isn’t it ?

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.

#79

No, it’s not you, Lauren. The output doesn’t have what we were expecting, or hoping for. This is probably getting into some serious debugging to figure out exactly why it’s crashing, and without a ShuttlePro, neither of us can run it in a debugger to see exactly what’s going on. The lack of the debug messages we were looking for leaves things a bit unclear.

I’ve seen instances where debug messages sent from a constructor don’t show up because the object hasn’t established a connection with stdout yet, so they get popped on the program’s internal queue, but the program crashes before the system can pop them off and that’s why we’re not seeing them. That usually implies that another thread is trying to access the object before it’s ready for use, but debugging multi-threaded apps is pretty tricky.

My thought is that the crash is occurring somewhere in the transferring of the object from the device list to the active list. I’ve looked through the code but I don’t understand the run-time design enough. I believe device discovery is happening when you click the ‘check’ box, but the active list is trying to display it before the constructor finished and is ready, but it still seems that the pointer to the device should be assigned by then and should be safe to at least display it in the list. A sequence diagram would be nice.

Or it could be something completely different. :confused:

#80

@MarkR1 not quite. The output from the -D flags is completely missed in Lauren’s pastebin.

#81

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.

#82

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.

#83

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.

#84

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

#85

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:

  1. Unplug the shuttle pro from the system
  2. Run ardour
  3. Open the Options->Surfaces page
  4. Activate the Shuttle Pro 2 in the device list
  5. Click on the Settings button to open the configuration window.
  6. 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.

#86

Hello Mark,

Thank you for your idea and extensive support !
I did several tests following your steps, with consistent ( the same ) result each time.

  1. unplug shuttle pro2 ( this shouldn’t be nessesairy, but for testing I happy to do so )
  2. start ardour ( 9.7.90 )
  3. edit > prefs > control surfaces
  4. ( & 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.
  5. 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.

#87

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. :slight_smile:

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.

#88

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 :

  1. ./ardbg
  2. ( gdb ) run -D controlproto,contourdesign
  3. in ardours > prefs > control surfaces > shuttlepro2 > click on checkbox so ardour crashes
  4. in konsole type : thread apply all bt
  5. followed by : c and enter to see all pages.
  6. 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 ).