Closed sadko4u closed 5 years ago
Finally, I've found the problem. There's suil_init call is missing in jalv_init function of jalv_gtk.c file:
int
jalv_init(int* argc, char*** argv, JalvOptions* opts)
{
suil_init(NULL, NULL, SUIL_ARG_NONE); // <-- This is missing
This is a problem of jalv host, not of LSP plugins. Now the UI works fine:
The suil_init()
call is in jalv_open()
.
The given command works fine for me as-is.
The suil_init() should be called before any X11 call is performed because it calls X11 backend which calls XInitThreads(). Otherwise the system crashes on uninitialized X11 threads.
I am so confused. Are we looking at the same code?
It is already called immediately before the call to jalv_init()
(where you put the additional call). Calling suil_init()
is nearly the very first thing jalv does. You're suggesting that calling XInitThreads()
twice in a row is the "fix"...
Is this 100% reliable? Does the crash ever happen with other (non-LSP plugins)?
I never experience a problem with my X11 based plugs (GxPlugins) and jalv.gtk2/3, nor do I receive a report of such a case.
Ok, let's start from 'beginning of universe'.
I'm looking into the code of officially released 'jalv-1.6.0' source code package. Looking to jalv.c, function main: jalv_init call, no suil_init call before.
Looking into jalv_gtk.c: gtk_init_with_args call.
Do we guarantee that gtk_init_with_args function calls XInitThreads()? No, it depends. Do we guarantee that gtk_init_with_args will call other X11 functions? No, but very possible.
Do we see a suil_init call in the jalv?
~/tmp/lv2/lv2-pack/jalv-1.6.0/src> grep -R suil_init *
No matches.
Now, a question for one billion dollars: how do you use your own library without initializing it?
Let's look into suil-0.10.2 source code, file host.c:
SUIL_API
void
suil_init(int* argc, char*** argv, SuilArg key, ...)
{
suil_argc = argc ? *argc : 0;
suil_argv = argv ? *argv : NULL;
#ifdef SUIL_WITH_X11
suil_load_init_module("suil_x11");
#endif
}
Hmm, let's look what suil_load_init_module does:
#ifdef SUIL_WITH_X11
static void
suil_load_init_module(const char* module_name)
{
void* const lib = suil_open_module(module_name);
if (!lib) {
return;
}
SuilVoidFunc init_func = suil_dlfunc(lib, "suil_host_init");
if (init_func) {
(*init_func)();
} else {
SUIL_ERRORF("Corrupt init module %s\n", module_name);
}
dlclose(lib);
}
#endif
Hmm, suil_host_init function call from a shared library. Let's look into x11.c:
SUIL_LIB_EXPORT
void
suil_host_init(void)
{
// This must be called first for Qt5 in Gtk2 to function correctly
XInitThreads();
}
Boom!
The verdict: gtk_init_with_args is called before the XInitThreads is called by the suil_x11 backend. suil_init is never called int jalv host. Is it reproducible on all systems? No. Is it a problem? Definitely yes.
https://github.com/drobilla/jalv/blob/master/src/jalv.c#L750
The verdict: don't waste a bunch of time debugging old code ;)
https://github.com/drobilla/jalv/blob/master/src/jalv.c#L750
The verdict: don't waste a bunch of time debugging old code ;)
It's not a joke and it's not funny. Not all distibutions use the sources from master branch of your git repository. Moreover, personally I (and many other developers) consider master branch as unstable branch and won't prefer to use it until special case. The latest release of jalv was published on 2017-01-04. So actually the problem is still persisting on systems that use the latest release and do not checkout the master branch of the git repository.
I am aware of how releases work, thanks.
Closing since this was fixed months ago.
Yep, I belive you'll publish the new release of jalv-gtk as soon as you can.
@sadko4u After fighting with your unconventional build variables and structure, I'm able to build your suite, and, non of your plugs works for me with jalv.gtk2/3 nor with qt5. However, here on debian/sid there is still as well jalv 1.6.0 in use , and, as said before, non of my own plugs using X11 have any problem with it, nor the ones I tried from other developers. And, for the record, repository's of mine, the master branch, is, always claimed as stable. Otherwise I use other branches to commit unstable features. I count myself not into your stance of "many other developers".
@sadko4u After fighting with your unconventional build variables and structure, I'm able to build your suite, and, non of your plugs works for me with jalv.gtk2/3 nor with qt5. However, here on debian/sid there is still as well jalv 1.6.0 in use , and, as said before, non of my own plugs using X11 have any problem with it, nor the ones I tried from other developers. And, for the record, repository's of mine, the master branch, is, always claimed as stable. Otherwise I use other branches to commit unstable features. I count myself not into your stance of "many other developers".
That's sad, it seems that you've done something wrong. Some distro builders like Arch, Ubuntu, Flatpak, FreeBSD and more hadn't so much problems. Have you even tried to read README.txt? Also, we're not discussing my plugins here, so please don't start the offtopic. I've found the reason - the topic has been closed. Good bye.
That's sad, it seems that you've done something wrong.
Sure, you do anything right, sorry for comment here. Your plugs are all the best and so on. . . . bye
That's sad, it seems that you've done something wrong.
Sure, you do anything right, sorry for comment here. Your plugs are all the best and so on. . . . bye
You may submit your bug report here: https://github.com/sadko4u/lsp-plugins , all discussions there.
You, open a bug report here, and I'm interested in jalv (I'm a watcher ). Your plugs, been the only one I'm aware of which having problems with the latest release of jalv. Consider, to reflect your own code, and check, if, what you do, is really necessary to create and build a user interface with X11. That's all I've to say.
I am pretty backed up on releases due to significant overhauls of pretty much the whole LV2 host stack, but I will see if a jalv (and maybe suil if necessary) release can be kicked out without having to release everything else too.
My best guess would be using threads in the UI. Which isn't necessarily "wrong", but is not a great idea and is very hard to actually get right.
The XInitThreads was originally added for Qt5 in Gtk2. I don't know the specific reason why it was required in that case.
Tried to build the latest git version of libraries to check how they behave with LSP but currently stuck with waftools: https://bitbucket.org/Moo7/waftools/issues/21/can-not-install-waftools
You don't need to install waf, there are no external dependencies to build other than python.
If you're working in a git tree you might need to do a fresh checkout though, since it has recently switched to being a submodule instead of a subtree.
Do I right understand that you've released only jalv and suil?
Yes.
jalv.gtk3 works:
jalv.gtk works:
jalv.gtkmm works:
jalv.qt4 crashes:
Thread 1 "jalv.qt4" received signal SIGSEGV, Segmentation fault.
0x00007ffff4f424e6 in __strlen_sse2 () from /lib64/libc.so.6
(gdb) thread apply all bt
Thread 4 (Thread 0x7fffe80b6700 (LWP 20437)):
#0 0x00007ffff4f9d169 in syscall () at /lib64/libc.so.6
#1 0x00007ffff6d51ff7 in () at /usr/lib64/libjack.so.0
#2 0x00007ffff6d399a5 in () at /usr/lib64/libjack.so.0
#3 0x00007ffff6d38a77 in () at /usr/lib64/libjack.so.0
#4 0x00007ffff6d38268 in () at /usr/lib64/libjack.so.0
#5 0x00007ffff6d501e6 in () at /usr/lib64/libjack.so.0
#6 0x00007ffff7bc0569 in start_thread () at /lib64/libpthread.so.0
#7 0x00007ffff4fa285f in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7fffea113700 (LWP 20436)):
#0 0x00007ffff4f70080 in nanosleep () at /lib64/libc.so.6
#1 0x00007ffff4f9a8a4 in usleep () at /lib64/libc.so.6
#2 0x00007ffff6d32417 in jack_port_get_latency_range () at /usr/lib64/libjack.so.0
#3 0x0000555555565b1a in jack_latency_cb ()
#4 0x00007ffff6d378c2 in () at /usr/lib64/libjack.so.0
#5 0x00007ffff6d37d3c in () at /usr/lib64/libjack.so.0
#6 0x00007ffff6d54b47 in () at /usr/lib64/libjack.so.0
#7 0x00007ffff6d501e6 in () at /usr/lib64/libjack.so.0
#8 0x00007ffff7bc0569 in start_thread () at /lib64/libpthread.so.0
#9 0x00007ffff4fa285f in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7fffea194700 (LWP 20435)):
#0 0x00007ffff7bc68ad in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1 0x00007ffff6d50bac in () at /usr/lib64/libjack.so.0
#2 0x00007ffff6d48825 in () at /usr/lib64/libjack.so.0
#3 0x00007ffff6d501e6 in () at /usr/lib64/libjack.so.0
#4 0x00007ffff7bc0569 in start_thread () at /lib64/libpthread.so.0
#5 0x00007ffff4fa285f in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7ffff7fb2c00 (LWP 20431)):
#0 0x00007ffff4f424e6 in __strlen_sse2 () at /lib64/libc.so.6
#1 0x00007ffff287d452 in XSetCommand () at /usr/lib64/libX11.so.6
#2 0x00007ffff28819d7 in XSetWMProperties () at /usr/lib64/libX11.so.6
#3 0x00007ffff62a51c3 in QWidgetPrivate::create_sys(unsigned long, bool, bool) () at /usr/lib64/libQtGui.so.4
#4 0x00007ffff6259a19 in QWidget::create(unsigned long, bool, bool) () at /usr/lib64/libQtGui.so.4
#5 0x00007ffff62abde0 in QX11EmbedWidget::QX11EmbedWidget(QWidget*) () at /usr/lib64/libQtGui.so.4
#6 0x00007fffdd9daf01 in suil_wrapper_new () at /usr/local/lib/suil-0/libsuil_x11_in_qt4.so
#7 0x00007ffff6f6e788 in open_wrapper () at /usr/local/lib/libsuil-0.so.0
#8 0x00007ffff6f6eb6b in suil_instance_new () at /usr/local/lib/libsuil-0.so.0
#9 0x000055555555f4f0 in jalv_ui_instantiate ()
#10 0x000055555556907e in jalv_open_ui ()
#11 0x00005555555628fb in main ()
(gdb)
jalv.qt5 crashes:
Thread 1 "jalv.qt5" received signal SIGSEGV, Segmentation fault.
0x00007ffff4a454e6 in __strlen_sse2 () from /lib64/libc.so.6
(gdb) thread apply all bt
Thread 6 (Thread 0x7fffda93d700 (LWP 20493)):
#0 0x00007ffff4aa0169 in syscall () from /lib64/libc.so.6
#1 0x00007ffff6d51ff7 in ?? () from /usr/lib64/libjack.so.0
#2 0x00007ffff6d399a5 in ?? () from /usr/lib64/libjack.so.0
#3 0x00007ffff6d38a77 in ?? () from /usr/lib64/libjack.so.0
#4 0x00007ffff6d38268 in ?? () from /usr/lib64/libjack.so.0
#5 0x00007ffff6d501e6 in ?? () from /usr/lib64/libjack.so.0
#6 0x00007ffff7bc0569 in start_thread () from /lib64/libpthread.so.0
#7 0x00007ffff4aa585f in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7fffdb7a4700 (LWP 20492)):
#0 0x00007ffff7bc9ea8 in read () from /lib64/libpthread.so.0
#1 0x00007ffff6d5144e in ?? () from /usr/lib64/libjack.so.0
#2 0x00007ffff6d54a51 in ?? () from /usr/lib64/libjack.so.0
#3 0x00007ffff6d501e6 in ?? () from /usr/lib64/libjack.so.0
#4 0x00007ffff7bc0569 in start_thread () from /lib64/libpthread.so.0
#5 0x00007ffff4aa585f in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7fffe80cc700 (LWP 20491)):
#0 0x00007ffff7bc68ad in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007ffff6d50bac in ?? () from /usr/lib64/libjack.so.0
#2 0x00007ffff6d48825 in ?? () from /usr/lib64/libjack.so.0
#3 0x00007ffff6d501e6 in ?? () from /usr/lib64/libjack.so.0
#4 0x00007ffff7bc0569 in start_thread () from /lib64/libpthread.so.0
#5 0x00007ffff4aa585f in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7fffdbfa5700 (LWP 20490)):
#0 0x00007ffff4a9b0bb in poll () from /lib64/libc.so.6
#1 0x00007ffff2e2e129 in ?? () from /usr/lib64/libglib-2.0.so.0
#2 0x00007ffff2e2e23c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3 0x00007ffff591abff in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4 0x00007ffff58c309a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5 0x00007ffff56f24da in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6 0x00007fffee2ab985 in ?? () from /usr/lib64/libQt5DBus.so.5
#7 0x00007ffff56f70ce in ?? () from /usr/lib64/libQt5Core.so.5
#8 0x00007ffff7bc0569 in start_thread () from /lib64/libpthread.so.0
#9 0x00007ffff4aa585f in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7fffeb309700 (LWP 20489)):
#0 0x00007ffff4a9b0bb in poll () from /lib64/libc.so.6
#1 0x00007ffff0852387 in ?? () from /usr/lib64/libxcb.so.1
#2 0x00007ffff0853fba in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3 0x00007fffee79e069 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#4 0x00007ffff56f70ce in ?? () from /usr/lib64/libQt5Core.so.5
#5 0x00007ffff7bc0569 in start_thread () from /lib64/libpthread.so.0
#6 0x00007ffff4aa585f in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7ffff7fad8c0 (LWP 20485)):
#0 0x00007ffff4a454e6 in __strlen_sse2 () from /lib64/libc.so.6
#1 0x00007ffff58c847c in QCoreApplication::arguments() () from /usr/lib64/libQt5Core.so.5
#2 0x00007fffee7a4383 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#3 0x00007fffee7a482d in QXcbIntegration::wmClass() const () from /usr/lib64/libQt5XcbQpa.so.5
#4 0x00007fffee7b8f12 in QXcbWindow::create() () from /usr/lib64/libQt5XcbQpa.so.5
#5 0x00007fffee7a576b in QXcbIntegration::createPlatformWindow(QWindow*) const () from /usr/lib64/libQt5XcbQpa.so.5
#6 0x00007ffff5e9f726 in QWindowPrivate::create(bool, unsigned long long) () from /usr/lib64/libQt5Gui.so.5
#7 0x00007ffff66840ed in QWidgetPrivate::create_sys(unsigned long long, bool, bool) () from /usr/lib64/libQt5Widgets.so.5
#8 0x00007ffff668477d in QWidget::create(unsigned long long, bool, bool) () from /usr/lib64/libQt5Widgets.so.5
--Type <RET> for more, q to quit, c to continue without paging--
#9 0x00007ffff6684cf9 in QWidget::winId() const () from /usr/lib64/libQt5Widgets.so.5
#10 0x00007fffd9caadd4 in suil_wrapper_new () from /usr/local/lib/suil-0/libsuil_x11_in_qt5.so
#11 0x00007ffff6f6e788 in open_wrapper () from /usr/local/lib/libsuil-0.so.0
#12 0x00007ffff6f6eb6b in suil_instance_new () from /usr/local/lib/libsuil-0.so.0
#13 0x000055555555f6a0 in jalv_ui_instantiate ()
#14 0x00005555555692a2 in jalv_open_ui ()
#15 0x0000555555562aab in main ()
Under valgrind --tool=memcheck
both jalv.qt4 and jalv.qt5 have started successfully.
Seems that not only LSP plugins are not working:
This dumb change fixed the problem:
diff -uNr jalv-1.6.2/src/jalv_qt.cpp jalv-1.6.2-new/src/jalv_qt.cpp
--- jalv-1.6.2/src/jalv_qt.cpp 2019-05-12 11:43:07.000000000 +0300
+++ jalv-1.6.2-new/src/jalv_qt.cpp 2019-06-07 02:11:19.653359088 +0300
@@ -324,10 +324,13 @@
extern "C" {
+static char *x_argv[] = { "test", NULL };
+static int x_argc = 1;
+
int
jalv_init(int* argc, char*** argv, JalvOptions* opts)
{
- app = new QApplication(*argc, *argv, true);
+ app = new QApplication(x_argc, x_argv, true);
app->setStyleSheet("QGroupBox::title { subcontrol-position: top center }");
return 0;
The description of problem I've found here: https://stackoverflow.com/questions/22243674/segmentation-fault-when-qt-qapplication-created-with-new
The quote:
QApplication has a special (and IMHO questionable) requirement for argc and argv. See the documentation: Warning: The data referred to by argc and argv must stay valid for the entire lifetime of the QApplication object. In addition, argc must be greater than zero and argv must contain at least one valid character string. If argc and argv get destroyed during runtime, undefined behavior occurs. It may work on some platforms and it will crash on others. Change your code accordingly and check if it fixes your problem.
Qt4 works fine:
Qt5 - not very good:
Related issue: https://github.com/sadko4u/lsp-plugins/issues/12
It seems that something is going wrong when wrapping X11UI with GTK2 and GTK3. jalv.qt works just fine and thows the UI.
Issuing the command: jalv.gtk http://lsp-plug.in/plugins/lv2/comp_delay_mono
I get error:
Here's the GDB backtrace: