smenc hangs on linux (ubuntu)

[codingisnuanced]

Reproduce

smenc in.wav out.sm

Should work

[swesterfeld]

You need to use either -m or -f to set the fundamental frequency of the input wav file in.wav. Still, it should not just hang. So I added an error message now to handle this case.

Anyway smenc is a quite low level tool. Probably the easiest way to morph using custom wav files is the instrument editor
described in this video https://www.youtube.com/watch?v=JlugWYPDp84

[codingisnuanced]

It works with that if-condition.

I tried using the plugin in Ardour on Ubuntu 20.04, but it crashes. An error showed once about an issue related to spectromorph and JACK.

Help me understand something; I am somewhat still discovering C++ features. How is it that a printf() at the very beginning of smenc.cc refused to show in terminal before the location at which you inserted the error message?

[swesterfeld]

I tried using the plugin in Ardour on Ubuntu 20.04, but it crashes.

Ok, I am running Ubuntu 20.04, and tried a build of Ardour7 from their git repo and SpectMorph from git (I wouldn't recommend that though, always use released versions, SpectMorph from git isn't stable at the moment). The LV2 plugin works without any issue. The VST plugin works after adding ~/.vst to the search path. The instrument editor works in both. So in principle this ought to work. Also note that I have been working with stable SpectMorph VST in Bitwig for years now, so the plugin should really be tested.

But to track down your problem with the plugin, maybe you can give me more information about how you installed it and which version exactly you used? Did you build from source? Install the .deb? Install the statically linked version?

Also relevant: if you have smjack, does that work? In general its a way to use SpectMorph without using the plugin. You just need a working JACK server.

How is it that a printf() at the very beginning of smenc.cc refused to show in terminal before the location at which you inserted the error message?

Typically this happens if you use a printf() without newline. So something like printf ("foo") would not show up, because the stdout stream is buffered internally for performance reasons and without newline it will simply go to the buffer (you could use fflush(stdout) to make it show up, whereas printf ("foo\n") would show up due to the newline.

[codingisnuanced]

Also relevant: if you have smjack, does that work? In general its a way to use SpectMorph without using the plugin. You just need a working JACK server.

So I get these warnings:
warning: XOpenIM failed warning: XCreateIC failed

Then it's always the case that just after I move the window, a seg fault happens and the program crashes:
Segmentation fault (core dumped)

Sometimes I get a report. When I do again, I will post it here. But what do you think is the problem?

[swesterfeld]

Can you start it in gdb and produce a backtrace of the crash? That is run

$ gdb smjack

Then type run to run it, and backtrace once it crashes?

[codingisnuanced]

So this is what is printed. The window is even yet to show for me to backtrace.

`$ gdb smjack
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 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:
http://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 smjack...
(No debugging symbols found in smjack)
(gdb) run
Starting program: /usr/bin/smjack
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff61d7700 (LWP 48984)]
[New Thread 0x7ffff58d5700 (LWP 48985)]

Thread 3 "smjack" received signal SIG32, Real-time event 32.
[Switching to Thread 0x7ffff58d5700 (LWP 48985)]
0x00007ffff7a0946e in epoll_wait (epfd=7, events=0x7ffff58d47f0, maxevents=32,
timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30 ../sysdeps/unix/sysv/linux/epoll_wait.c: No such file or directory.`

[swesterfeld]

Ok, you need to let it run a little longer inside gdb until it really crashes. So start it in gdb, type run to run it. If you get some signal (like in your case), this is not the actual crash yet, so just type continue to let it continue. You may have to repeat typing continue a few times until it really crashes. If it crashes, you'll get a message like

Thread 5 "smjack" received signal SIGSEGV, Segmentation fault.

from gdb. If you type backtrace once this has happened, then you should be able to produce an actual stacktrace.

Also since you mentioned that it happens after moving a window, may I ask what window manager / compositor / desktop environment you are using?

• KDE or Gnome? Or something else entierly?
• X11 or Wayland?
  (I am developing in an KDE/X11 setup, if yours is different this could explain why it works here and not for you).

It would also be interesting to know what version of smjack we're talking about here. Did you compile from git? Or compile the official released version? Or install the .deb package from spectmorph.org?

[codingisnuanced]

Here is the dump of my console after running gdb smjack until it crashed, then typing backtrace.

`gdb) run
Starting program: /usr/bin/smjack
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff61d7700 (LWP 133688)]
[New Thread 0x7ffff58d5700 (LWP 133689)]

Thread 3 "smjack" received signal SIG32, Real-time event 32.
[Switching to Thread 0x7ffff58d5700 (LWP 133689)]
__libc_disable_asynccancel ()
at ../sysdeps/unix/sysv/linux/x86_64/cancellation.S:102
102 ../sysdeps/unix/sysv/linux/x86_64/cancellation.S: No such file or directory.
(gdb) continue
Continuing.
[Thread 0x7ffff58d5700 (LWP 133689) exited]
[New Thread 0x7ffff58d5700 (LWP 133690)]
[New Thread 0x7ffff5093700 (LWP 133691)]
warning: XOpenIM failed
warning: XCreateIC failed

Thread 1 "smjack" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff69c1940 (LWP 133684)]
0x00007ffff71cc884 in XUnsetICFocus () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) backtrace
#0 0x00007ffff71cc884 in XUnsetICFocus ()
from /lib/x86_64-linux-gnu/libX11.so.6
#1 0x00007ffff7dcfec5 in puglProcessEvents () at pugl_x11.c:680
#2 0x00007ffff7dad775 in SpectMorph::EventLoop::process_events ()
at smeventloop.cc:39
#3 0x0000555555558ac0 in ?? ()
#4 0x00007ffff790e083 in __libc_start_main (main=0x555555558800, argc=1,
argv=0x7fffffffdff8, init=, fini=,
rtld_fini=, stack_end=0x7fffffffdfe8)
at ../csu/libc-start.c:308
#5 0x0000555555558d0e in ?? ()
(gdb) continue
Continuing.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) [Thread 0x7ffff5093700 (LWP 133691) exited]
[Thread 0x7ffff58d5700 (LWP 133690) exited]
[Thread 0x7ffff61d7700 (LWP 133688) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.`

Regarding my window manager, my $XDG_CURRENT_DESKTOP and $XDG_SESSION_TYPE environment variables show I am using GNOME/X11. What do you made of that?

Regarding how I installed SpectMorph, I was using smjack from the deb on the website, but I also tried to look at the source (0.5.2 from website), which is how I came across the hanging issue. However, maybe I used the source's smjack; this would be the case if make install replaces the deb's smjack. You tell me. Anyway, I am currently building from source (0.5.x branch).

[codingisnuanced]

Regarding how I installed SpectMorph, I was using smjack from the deb on the website, but I also tried to look at the source (0.5.2 from website), which is how I came across the hanging issue. However, maybe I used the source's smjack; this would be the case if make install replaces the deb's smjack. You tell me. Anyway, I am currently building from source (0.5.x branch).

I can confirm the same error occurs in both the deb and source. I just built 0.5.x and ran smjack.

[swesterfeld]

Ok, so thanks to your backtrace, I think I know what the problem is: on your system XOpenIC returns NULL, which on your system leads to a crash later if XUnsetICFocus is called with a NULL pointer.

Please test if you still experience problems if you build from branch x-open-im-fix or apply the changes in this commit
e7219f3 - it's probably best to uninstall the .deb first to be certain that the compiled-from-source version is used.

See also this commit in upstream pugl: lv2/pugl@2e0fb50