Ctrlr 5.6.23 (master branch) builds on Debian Bullseye, but crashes when opening a (new) panel

[tomlem]

After changing line 51 and line 93 of the Linux makefile into VST3_PLATFORM_ARCH := $(shell uname -m) ctrlr 5.6.23 compiles on Debian Bullseye (g++ (Debian 10.2.1-6) 10.2.1 20210110). It opens, the preferences can be set and the build-in tools can be opened, but the midi device can not be set. When opening a panel (new or existing) it crashes (crashReport attached) while the output in the shell reads: BFD::write_output closed read handle: file: /home/tom/build/ctrlr/Builds/LinuxMakefile/build/Ctrlr temp:.

Ctrlr.crash reads:

Ctrlr crash at: 17 May 2021 13:10:50
Stack trace:
./Ctrlr(+0x6767e7) [0x561592fbe7e7]
./Ctrlr(+0x5bb374) [0x561592f03374]
./Ctrlr(+0x665c2d) [0x561592fadc2d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140) [0x7f1e8c65b140]
./Ctrlr(+0x916b26) [0x56159325eb26]
./Ctrlr(+0x916ed4) [0x56159325eed4]
./Ctrlr(+0xa44c40) [0x56159338cc40]
./Ctrlr(+0xa4e42f) [0x56159339642f]
./Ctrlr(+0xa4ef36) [0x561593396f36]
./Ctrlr(+0x951478) [0x561593299478]
./Ctrlr(+0x93e842) [0x561593286842]
./Ctrlr(+0x5ca274) [0x561592f12274]
./Ctrlr(+0x6f6ec2) [0x56159303eec2]
./Ctrlr(+0x6f5e03) [0x56159303de03]
./Ctrlr(+0x6f5fd7) [0x56159303dfd7]
./Ctrlr(+0x2bcbbc) [0x561592c04bbc]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f1e8bff3d0a]
./Ctrlr(+0x5bb0ba) [0x561592f030ba]

[keinstein]

Take a look at https://github.com/keinstein/ctrlr/tree/lua5.2 Does it help?

Edit: I had problems with the included mixed libusb and lua libusb Edit2: So far only the LinuxMakefile build system has been updated. And you need to install liblua5.2-dev, libluabind-dev, boost-dev and lua-bitop-dev.

[keinstein]

It could be a duplicate of #168 In that case the backtrace is useless.

[tomlem]

It doesn't build. Error code: Makefile:336: *** target pattern contains no '%'. Stop.

[keinstein]

As far as I can see this is an issue with Projucer and VST3 plugins. I always use one of

make -f pchbuild.mk CONFIG=Debug Standalone
make -f pchbuild.mk CONFIG=Release Standalone

[tomlem]

Both suggested commands gave the same error code as mentioned earlier:
Makefile:336: *** target pattern contains no '%'. Stop.

After changing line 51 of the Makefile to: VST3_PLATFORM_ARCH := $(shell uname -m) it compiled, but only in debug mode (the release mode stubbornly sticked to 'no % in target pattern'

After deleting the existing Ctrlr settings file, I opened some demo panels and they were working fine. Midi in and out was working fine too. But loading a complex panel I am working on using Ctrlr version 5.3.201 caused a crash in this version.

Crash file:

Ctrlr crash at: 21 Jun 2021 15:46:02 Stack trace: ./Ctrlr-Debug(+0x40e7ba) [0x557fdc3fd7ba] ./Ctrlr-Debug(+0x1b07c8) [0x557fdc19f7c8] ./Ctrlr-Debug(+0x40e883) [0x557fdc3fd883] /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140) [0x7f9ce2a9f140] ./Ctrlr-Debug(+0x7a577a) [0x557fdc79477a] ./Ctrlr-Debug(+0x7a58ae) [0x557fdc7948ae] ./Ctrlr-Debug(+0x7a73bf) [0x557fdc7963bf] ./Ctrlr-Debug(+0x7ab241) [0x557fdc79a241] ./Ctrlr-Debug(+0x7aadc1) [0x557fdc799dc1] ./Ctrlr-Debug(+0x7aaab5) [0x557fdc799ab5] ./Ctrlr-Debug(+0x7aa78b) [0x557fdc79978b] ./Ctrlr-Debug(+0x7a3512) [0x557fdc792512] ./Ctrlr-Debug(+0x7b9c62) [0x557fdc7a8c62] ./Ctrlr-Debug(+0x7b9ec4) [0x557fdc7a8ec4] ./Ctrlr-Debug(+0xe748f6) [0x557fdce638f6] ./Ctrlr-Debug(+0xab8d1b) [0x557fdcaa7d1b] ./Ctrlr-Debug(+0xab8838) [0x557fdcaa7838] ./Ctrlr-Debug(+0x830012) [0x557fdc81f012] ./Ctrlr-Debug(+0x7e195b) [0x557fdc7d095b] ./Ctrlr-Debug(+0x7e35b7) [0x557fdc7d25b7] ./Ctrlr-Debug(+0x7e309e) [0x557fdc7d209e] ./Ctrlr-Debug(+0x230f78) [0x557fdc21ff78] ./Ctrlr-Debug(+0x652af8) [0x557fdc641af8] ./Ctrlr-Debug(+0x6b25cf) [0x557fdc6a15cf] ./Ctrlr-Debug(+0x4c6feb) [0x557fdc4b5feb] ./Ctrlr-Debug(+0x4d8cd8) [0x557fdc4c7cd8] ./Ctrlr-Debug(+0x4d5dda) [0x557fdc4c4dda] ./Ctrlr-Debug(+0x4d09eb) [0x557fdc4bf9eb] ./Ctrlr-Debug(+0x4cc8be) [0x557fdc4bb8be] ./Ctrlr-Debug(+0x4c7c31) [0x557fdc4b6c31] ./Ctrlr-Debug(+0x4c255f) [0x557fdc4b155f] ./Ctrlr-Debug(+0x4bccdd) [0x557fdc4abcdd] ./Ctrlr-Debug(+0x4bc179) [0x557fdc4ab179] ./Ctrlr-Debug(+0x4bc07e) [0x557fdc4ab07e] ./Ctrlr-Debug(+0x1b03bc) [0x557fdc19f3bc] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f9ce2437d0a] ./Ctrlr-Debug(+0x1b02ca) [0x557fdc19f2ca]

Ctrlr debug log Log started: 21 Jun 2021 3:43:50pm

[INFO ][15:45:17:000113]: CtrlrLuaManager::ctor create debugger

[INFO ][15:45:17:000159]: Open FAILED: [E-MU XMidi1X1 Tab] [INFO ][15:45:17:000159]: Open FAILED: [E-MU XMidi1X1 Tab]

[WARN ][15:45:31:000138]: CtrlrPanelMIDIInputThread::run stopping [WARN ][15:45:31:000638]: CtrlrPanelMIDIInputThread::run stopping

[keinstein]

With the parameter Standalone the VST3 plugin does not get built, so the changes to the Makefile are not necessary.

Can you run Ctrlr from gdb?

gdb Ctrlr-Debug
r
bt full

and please, put the backtrace here?

you can quit gdb with the command q or quit.

There are several issues with JUCE assertions in Debug mode. We should take them seriously as they may lead to other errors and even crashes.

[tomlem]

ok

[tomlem]

~/build/ctrlr/Builds/LinuxMakefile/build$ gdb Ctrlr-Debug GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from Ctrlr-Debug... (gdb) r bt full Starting program: /home/tom/build/ctrlr/Builds/LinuxMakefile/build/Ctrlr-Debug bt full [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". JUCE v6.0.7 CTRLR:initialise params "bt full" [Detaching after fork from child process 5280] [Detaching after fork from child process 5281] [New Thread 0x7ffff5dcb700 (LWP 5284)] CtrlrManagerVst::ctor CtrlrLinux::getDefaultPanel, libr_open succeeded for binary [self] BFD::write_output closed read handle: file: /home/tom/build/ctrlr/Builds/LinuxMakefile/build/Ctrlr-Debug temp: [New Thread 0x7ffff54b2700 (LWP 5285)] [Detaching after fork from child process 5287] [Detaching after fork from child process 5288] [Detaching after fork from child process 5289] CtrlrLuaManager::ctor create debugger [New Thread 0x7ffff4cb1700 (LWP 5319)] [New Thread 0x7fffe7fff700 (LWP 5320)] CtrlrPanel::restoreState Open FAILED: [A] Open FAILED: [B] CtrlrPanel::bootstrapPanel CtrlrPanel::setProgram [New Thread 0x7fffe77fe700 (LWP 5321)] Open OK: [E-MU XMidi1X1 Tab MIDI 1] [New Thread 0x7fffe6ffd700 (LWP 5322)] Open OK: [E-MU XMidi1X1 Tab MIDI 1] CtrlrPanelWindowManager::windowClosedButtonPressed [Detaching after fork from child process 5323] [Detaching after fork from child process 5324] JUCE Assertion failure in juce_String.cpp:324

Thread 1 "Ctrlr-Debug" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff76df087 in kill () at ../sysdeps/unix/syscall-template.S:120 120 ../sysdeps/unix/syscall-template.S: Bestand of map bestaat niet. (gdb) q A debugging session is active.

Inferior 1 [process 5276] will be killed.

Quit anyway? (y or n) y

[tomlem]

gdb_backtrace_2021_06_21.txt

[tomlem]

I have closed it unintentionally.

[tomlem]

I had closed it unintentionally.

[keinstein]

can you switch to the branch lua5.2, please?

Currently, the Ctrlr crashes because it does not know how to convert a non-ASCII string to Unicode (probably utf-8).

Which Editor did you use to generate that string: "Loaded \273 180 bytes from sysex file" ? Did you use the internal Lua editor or some kind of external Editor. Theoretically the source code should be UTF-8. The character \273 is neither UTF-8 nor ASCII.

So probably also my patch will fail.

Can you please send the panel it to me via email for further testing? Maybe we can avoid these crashes in debug mode.

Edit: Address removed

[tomlem]

Panel and .syx file sent via email. That .syx file was loaded using (a lua structure in) the panel. Tomorrow I wil compile branch lua 5.2

Thomas

[tomlem]

Immediately after compilation (yesterday) the program correctly loaded the .syx file into the ctrlr memory block and then sent it correctly to the sound module as well. That's why I said in my first comment that the MIDI in and out went correctly. Only on subsequent attempts did the program freeze. There may be something stuck in memory or in the configuration file?

[tomlem]

I've got these errors while trying to compile ctrlr-lua5.2. On my pc both Lua 5.1.5 and Lua 5.3.3 are installed

~/build2/ctrlr-lua5.2/Builds/LinuxMakefile$ make -f pchbuild.mk CONFIG=Debug Standalone
Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'lua5.1', required by 'lua5.2-bitop', not found
Makefile:295: *** target pattern contains no '%'. Stop.

The last line if this error message disappears when lines 51 and 93 of the Makefile are replaced with VST3_PLATFORM_ARCH := $(shell uname -m)

After replacing these lines the compilation attempt then runs next output:

~/build2/ctrlr-lua5.2/Builds/LinuxMakefile$ make -f pchbuild.mk CONFIG=Debug Standalone
Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'lua5.1', required by 'lua5.2-bitop', not found
for d in Release Debug ; do \
if test \( "clean-$d.stamp" -nt "clean-Debug.stamp" \) -o \( ! -f "clean-$d.stamp" \) ; then touch "clean-Debug.stamp" ; fi ; \
    echo "cleaning because of clean-$d.stamp -nt clean-Debug.stamp \) -o \( ! -f clean-$d.stamp \)" ; \
    make clean ; \
done
cleaning because of clean-Release.stamp -nt clean-Debug.stamp \) -o \( ! -f clean-Release.stamp \)
make[1]: Map '/home/tom/build2/ctrlr-lua5.2/Builds/LinuxMakefile' wordt binnengegaan
Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'lua5.1', required by 'lua5.2-bitop', not found
Cleaning Ctrlr
make[1]: Map '/home/tom/build2/ctrlr-lua5.2/Builds/LinuxMakefile' wordt verlaten
cleaning because of clean-Debug.stamp -nt clean-Debug.stamp \) -o \( ! -f clean-Debug.stamp \)
make[1]: Map '/home/tom/build2/ctrlr-lua5.2/Builds/LinuxMakefile' wordt binnengegaan
Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'lua5.1', required by 'lua5.2-bitop', not found
Cleaning Ctrlr
make[1]: Map '/home/tom/build2/ctrlr-lua5.2/Builds/LinuxMakefile' wordt verlaten
touch clean.stamp
CTRLR[linux]: Compile PCH
stadfx.h
../../Source/Core/stdafx.h:9:10: fatal error: lua.h: Bestand of map bestaat niet
    9 | #include "lua.h"
      |          ^~~~~~~
compilation terminated.
make: *** [pchbuild.mk:16: build/stdafx.h.gch] Fout 1

[keinstein]

apt-get install liblua5.2-dev

[tomlem]

sudo apt-get install liblua5.2-dev Package lists are being read... Done Building requirements tree... Done Status information is being read... Done liblua5.2-dev is already the latest version (5.2.4-1.1+b3). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded

[tomlem]

After installing liblua5.1-dev and after replacing lines 51 and 93 of the Makefile with VST3_PLATFORM_ARCH := $(shell uname -m) it is compiling now.

[tomlem]

Back trace of GDB for the following actions:

Opening panel (the one I sent you), setting up Midi channels and opening Tools/MIDI window -- succeeded; loading the same .syx file as I sent you -- succeeded; sending this .syx file to the sound module -- succeeded; receiving a bulk dump of the setup from these sound module -- succeeded; sending the received setup bulk dump to a file on the pc -- succeeded; opening preferences and setting some preferences -- succeeded; closing this panel -- succeeded; opening a new panel -- while changing directory on pc in search for other panel -- freezed

See attached file.

gdb_backtrace_2021_06_22.txt

Thomas

[keinstein]

Can you reproduce this crash? I assume as soon as you install kdialog or zenity the problem disappears.

Some explanation: JUCE tries to display the text “Go up to parent directory” as tooltip and assumes that the file chooser dialog has already a tooltip open. JUCE consideres this a bug (in JUCE code).

This is one of the many Linux bugs that JUCE has.

[tomlem]

After installing kdialog I couldn't reproduce the previous crash. I loaded another, a work in progress panel and when trying to display some lua structures in the lua window the program was freezing.

I sent this (work in progress) panel to you via email.

gdb_backtrace_2021_06_22_20:15.txt

[keinstein]

@RomanKubiak can you have a look at Source/Core/CtrlrPanel/CtrlrPanelMIDISnapshot.{cpp,h}?

It seems that there are several ways to stop the thread in this class. The Destructor unconditionally stops the thread, which hits a JUCE assertion if the thread is not running.

[tomlem]

I'm testing the lua5.2 version some more.

Some lua functions, especially those using the bitop library, are no longer working. I added local bit = require("bit") as first line in these functions (b.i. the functions lsTN1, lsTN2... in the panel I sent you). Error message:

Callback error: [lsTN1] 
At line [-1]: [C]
What: C
Namewhat: method
Name: sendMidiMessageNow
Error message: No matching overload found, candidates:
void sendMidiMessageNow(CtrlrPanel&,CtrlrMidiMessage&) 
At line [-1]: [C]
What: C
Namewhat: method
Name: sendMidiMessageNow
Error message: No matching overload found, candidates:
void sendMidiMessageNow(CtrlrPanel&,CtrlrMidiMessage&).
Method disabled
JUCE Assertion failure in juce_DragAndDropContainer.cpp:585

gdb_backtrace_NoMatchingOverloadFound_2021_06_25_11:11.txt

In the lua window it is no longer possible to close a lua function by clicking along its name in the tab bar.

[keinstein]

@RomanKubiak can you have a look at Source/Core/CtrlrPanel/CtrlrPanelMIDISnapshot.{cpp,h}?

I added a suggestion to fix this issue to branch keinsteins_fixes

I added local bit = require("bit") as first line in these functions (b.i. the functions lsTN1, lsTN2... in the panel I sent you).

I didn't recognise that it doesn't work. Ctrlr has two functions that initialise Lua and probably I updated the wrong one. Both should load bit by default, now.

JUCE Assertion failure in juce_DragAndDropContainer.cpp:585

This is not related to sendMidiMessageNow. It is because Ctrlr left it to JUCE to guess the pointer that generates the drag event. Now, I changed the code that the pointer device from the event is sent to JUCE so that it can't guess wrongly.

The sendMidiMessageNow issue is something different. How do other versions behave? Whats on Windows, Mac/iOS other Linux builds?

[keinstein]

I tried your two panels, but I didn't get the Lua error. If it persists, please make a minimal example panel, which has just one button that triggers the error, so that I can debug it.

[tomlem]

As you suggested I've made a simple test panel. Its is working using Ctrlr 5.3.201 (of course without `local bit = require("bit")) but not using lua 5.2 (withlocal bit = require("bit")` as first argument in the function).

gdb_backtrace_Bitoptest_2021_06_26_17:00.txt Ctrlr Panel_1_0_Hell-O-Kitty_BitopTest_2021-06-26_13-04.zip

[keinstein]

CtrlrMidiMessage has no constructor that takes a Lua array and automatic conversion to and from CtrlrLuaObjectWrapper is not set up. As I can't find any information about automatic type conversion in Lua I assume that code like CrtlrMidiMessage({0xf0, ... , 0xf7}) should not work with any Lua version.

@RomanKubiak What is the right way to do?

[keinstein]

@tomlem does https://github.com/RomanKubiak/ctrlr/pull/400 work for you?

[tomlem]

Hi Tobias,

That's really good news.

At the moment I don't have access to my PC. I will definitely test it out and report on it in a few days.

Thomas

[tomlem]

Hi Tobias,

After executing git clone https://github.com/keinstein/ctrlr.git and after reading the updated documentation (ctrlr/README.md) to know what dependency packages I had to install (on my system, Debian Bullseye, the specific version 1.0 of libusb was required), I executed cd ctrlr/Builds/LinuxMakefile/ and then make -f pchbuild.mk CONFIG=Debug Standalone

The compilation process went well.

After playing with this version for an hour or so, my impression of it is very good. In the next days I will test it even more in depth.

Thomas

[tomlem]

Some remarks @keinstein

• LANG=C ./build.sh Release Standalone also compiles without errors
• When I try to open a panel there appears a couple of errors in the terminal but the panel appears to be working normally (Error: The code for function or variable json4lua does not define json4lua // Error: The code for function or variable debugger.lua does not define debugger.lua.). When I try to close a panel (File>Close) there appears a requester (Save Discard Cancel). When clicking on Save or on Discard not only the panel is closing but Ctrlr also. See attached file "DBGinfo"
• The lua method "lsTN1" in the attached panel gives this error in the terminal (I started Ctrlr from terminal): Callback error: [lsTN1] At line [-1]: [C] Error message: No matching overload found, candidates: void __init(luabind::argument const&,JMemoryBlock&) void __init(luabind::argument const&,MidiMessage const&) void __init(luabind::argument const&,CtrlrLuaObjectWrapper const&) void __init(luabind::argument const&,String const&) Method disabled

Ctrlr Panel_1_0_Hell-O-Kitty_BitopTest_2021-06-26_13-04.zip DBGinfo_terminal.zip

[keinstein]

Regarding the issues: I have no idea. Can you confirm that it works with your version on Linux?

[keinstein]

I was too fast. Your second point is unrelated to this issue. It is merely a side effect that Ctrlr does not crash anymore when you rename a function. The code checks that the name of the function is defined after compiling the source. Otherwise it gives the warning. At that point I didn't think about the fact that a table can be called as a function under certain circumstances.

That code is just diagnostic. The function cannot be called from the panel if it is not defined.

Regarding the Save/Discard etc. Its probably completely unrelated to this patches. These are bugs that have been available for a long time. I compile using the address sanitizer, which is very picky about such problems. Actually it has be developed to find these issues. If you remove -fsanitize=address from the compiler options, Ctrlr may and may not crash at this point. If it does not crash you have corrupted memory. This may not be a problem but it is still a bug. I'd suggest to use the address sanitizer always on any platform that supports it (Mac OS X or Linux or MingW*) in order to early find such issues, not only after someone fixed another one.

[tomlem]

I can confirm that so far it is working really good on my system (System: Kernel: 5.10.0-10-amd64 x86_64 bits: 64 Desktop: GNOME 3.38.6 Distro: Debian GNU/Linux 11 (bullseye)) EXCEPT the problem mentioned in the third remark in my previous post.

[keinstein]

Could we move the discussion of the build to https://github.com/RomanKubiak/ctrlr/pull/400 , please?

[keinstein]

Just for the records: Automatic conversion from Lua objects to to CtrlLuaObjectWrapper is not registered with luabind. And then: what is the best? JMemoryBlock, MidiMessage, String? I try to implement the automatic convertion to CtrlLuaObjectWrapper. And I expect it to break lots of things as it is theoretically used in many places but practically in none of them.

[keinstein]

@tomlem Take a look at https://github.com/keinstein/ctrlr/tree/master, please