Carla segmentation fault

[6r1d]

Bug Summary

Immediate segmentation fault happens when I add Carla Rack or Carla Patchbay. It might be either Carla or LMMS issue, I'll move it to falkTX's repo if I should.

OS: Ubuntu 18.04.4 LTS (Bionic) Hardware: Lenovo IdeaPad 330S-15ARR QT version: 5.9.5 GCC version: 7.5.0 Last commit in log: a05306

UPD: if anyone can tell me how to differentiate if wrong data is being fed into Carla Patchbay / Rack, or a current version causes an error by itself, please do.

Steps to reproduce

• Open Lmms build in GDB (outside works the same): gdb lmms
• Type run in GDB to proceed
• Add Carla Rack or Carla Patchbay as an instrument
• See LMMS frozen and GDB showing a log below

Expected behavior

Being able to add Carla Patchbay / Carla Rack.

Actual behavior

Segmentation fault.

Affected LMMS versions

1.2.1.696, local build. Sorry, I can't try to reproduce this bug with stable-1.2 branch, because it doesn't seem to support my current Qt version:

Found unsuitable Qt version "5.9.5" from /usr/bin/qmake, this code requires Qt 4.x

Logs

Click to expand

[New Thread 0x7fff0423e700 (LWP 8192)]

Thread 29 "InstrumentLoade" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff0423e700 (LWP 8192)]
0x00007fff07bdefd7 in CarlaInstrument::CarlaInstrument(InstrumentTrack*, Plugin::Descriptor const*, bool) ()
   from /home/grid/tools/lmms/plugins/libcarlabase.so

[iankressin]

I'm experiencing the same problem on Ubuntu 20.04, but gdb's logs are different in my case

As gdb suggests, the crash is in line 175 of /plugins/carlabase/carla.cpp which is the following: fHandle = fDescriptor->instantiate(&fHost);

Printing the fDescriptor variable in gdb returns $1 = (const NativePluginDescriptor *) 0x0, which is being used to instantiate the plugin.

@6r1d is it possible to you generate the debugging version and check for the fDescriptor value.

Maybe this can indicate something, I'm trying to dig deeper on it.

[6r1d]

Hello! Glad to see this discussion will continue. :-)

@6r1d is it possible to you generate the debugging version and check for the fDescriptor value.

I'll try to start from the beginning. I am making a new clone of LMMS to my home directory as lmms_master, then I do something like cmake .. -DCMAKE_INSTALL_PREFIX=../target/ -DCMAKE_BUILD_TYPE=Debug, run gdb, run LMMS in gdb. Currently I see:

Thread 33 "InstrumentLoade" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffef078e700 (LWP 20811)]
0x00007ffefa39bc15 in CarlaInstrument::CarlaInstrument (this=0x7fff30060020, 
    instrumentTrack=0x7ffff7ed8fa0, 
    descriptor=0x7ffef3212220 <carlarack_plugin_descriptor>, isPatchbay=false)
    at /home/grid/lmms_master/plugins/carlabase/carla.cpp:175
175     fHandle = fDescriptor->instantiate(&fHost);

Will this help? If not, tell me the commands you'd prefer me to run.

(gdb) print fDescriptor
$1 = (const NativePluginDescriptor *) 0x0
(gdb) print fHandle
$2 = (NativePluginHandle) 0x0

[iankressin]

Will this help? If not, tell me the commands you'd prefer me to run.

Yepp. Both of our programs are crashing at the same line as your fDescriptor is NULL too.

I'll do some more investigation and keep you.

[PhysSong]

It may happen when LMMS fails to find Carla plugin library. Have you installed separate Carla package? LMMS' Carla plugins won't work without them.

[6r1d]

UPD: I was able to build Carla by re-downloading the whole repo and rebuilding every little thing. Let's see how LMMS builds.

UPD2: Carla patchbay and Carla rack work perfectly.

Now, maybe Carla shouldn't be in the menu if it's not found at all and the message about it being unavailable should be in the config? Let's decide that before closing the issue.

---

I tried to test your idea locally, but so far I can't prove or disprove it, since when I am trying to build Carla by simply typing make, I see this log:

../../build/modules/Release/carla_plugin.a: member ../../build/modules/Release/carla_plugin.a(CarlaPluginBridge.cpp.o) in archive is not an object
collect2: error: ld returned 1 exit status
Makefile:122: recipe for target '../../bin/libcarla_standalone2.so' failed
make[1]: *** [../../bin/libcarla_standalone2.so] Error 1

I wonder if it's version dependent.

[iankressin]

@6r1d I'll try to replicate these steps on my machine.

Now, maybe Carla shouldn't be in the menu if it's not found at all and the message about it being unavailable should be in the config? Let's decide that before closing the issue.

Maybe we should leave the plugins in the menu even if they're not installed, so new users can be aware of it. But throw an error message saying that the plugin is not installed, and obviously, fix the segfault that terminates lmms

[hermestrimegistus]

Is this issue fixed? What's the work around? It's 2023 and issue still exists.

[ghost]

Hello.

Issue still persists. Running the latest Arch Linux X86_64. QT 5.5.12 GCC 13.2.1 Using the latest version of master (via fork) as of this comment (commit c991a85)

[zonkmachine]

Hello.

Issue still persists. Running the latest Arch Linux X86_64. QT 5.5.12 GCC 13.2.1 Using the latest version of master (via fork) as of this comment (commit c991a85)

If you have carla and the carla development packages both installed, try forcing a recompile by removing CMakeCache.txt . If that doesn't work, I'd try removing the .so files with names starting with libcarla in the /build/plugins directory and then recompile.