Sooperlooper segfaults when launched from slgui

Addressing your comments in reverse order: the -U option is used to connect the sooperlooper engine to an extant slgui session for OSC control. I'm not sure why it's undocumented, and it probably shouldn't segfault when it fails, but that's somewhat expected behaviour (although still a bug).

As for slgui failing to start could you post the error you receive in the console? For me, slgui only fails to start the engine if I don't previously have jackd running.

I had another go at using sooperlooper today, and it turns out that my workaround just delays the problem. Starting up sooperlooper from the command line with no arguments works fine, but as soon as I start slgui on a separate command line, the engine segfaults and slgui tries to spawn its own engine and fails. It's starting to look like something of an OSC problem.

The behaviour is similar to that described at an old thread here:
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2005-October/010554.html

The solution there was to install liblo 0.16.4 from an RPM. I have liblo 0.23-2.1build1 installed from universe.

root@cheese:~# dpkg --list | grep liblo
ii liblo0 0.23-2.1build1 Lightweight OSC library
ii liblo0-dev 0.23-2.1build1 Lightweight OSC library -- development files
root@cheese:~# dpkg --list | grep soop
ii sooperlooper 1.0.8c-2ubuntu1 Looping Sampler

root@cheese:~# jackd -dalsa -d hw:1 -r 44100 -p 1024 -n 4 &
[1] 8447
root@cheese:~# jackd 0.102.20
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:1|hw:1|1024|4|44100|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 44100Hz, period = 1024 frames, buffer = 4 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 4 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 4 periods for playback

root@cheese:~#
root@cheese:~# sooperlooper
SooperLooper 1.0.8c
Copyright 2005 Jesse Chappell
OSC server URI (network) is: osc.udp://cheese:9951/

Up to this point jackd and the sooperlooper engine have started successfully. Upon running slgui, the engine segfaults.

Thanks for the additional information. I do wish I could replicate it locally. Could you please post the output of running slgui from the command line to show the crash? I'm curious at which point it crashes.

slgui output with jack running, but no engine running yet:

roger@cheese:~$ slgui
slgui: our URL is osc.udp://cheese:10400/
execing: 'sooperlooper -q -U osc.udp://cheese:10400/ -p 9951 -l 1 -c 2 -t 40 -m "/home/roger/.sooperlooper/default_midi.slb"'

slgui: spawned new engine
slgui: gave up on spawned engine

Only part of GUI is rendered at the "spawned new engine" point and after a short delay, the "gave up" line appears with a GUI message box: "No response from sooperlooper engine process. Please make sure the JACK server is running. Also check that the system's hostname resolves correctly"

The slgui output is the same with a sooperlooper engine running already, but I think this is because slgui crashes the existing one before trying to start a new one and crashing that one too.

Output of gdb slgui has one extra line of interest;
(gdb) run
Starting program: /usr/bin/slgui
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1220606256 (LWP 17898)]
(no debugging symbols found)
(no debugging symbols found)
---snip---
(no debugging symbols found)
(no debugging symbols found)
slgui: our URL is osc.udp://cheese:10785/
[New Thread -1222669424 (LWP 17907)]
execing: 'sooperlooper -q -U osc.udp://cheese:10785/ -p 9951 -l 1 -c 2 -t 40 -m "/home/roger/.sooperlooper/default_midi.slb"'

slgui: spawned new engine
OSC thread poll failed: Interrupted system call
slgui: gave up on spawned engine

I couldn't turn up any clues about that extra line, it seems to be an effect of the engine segfault rather than a cause.

I'm facing a similar problem with self-compiled sooperlooper v1.6.2 - it really seems that the engine is segfaulting.
Has anyone found any solution to this, yet?

I've recompiled sooperlooper v1.6.3 with debugging symbols and it seems that mine is segfaulting in "SooperLooper::MidiBridge".
Here's gdb's output:

0x08081c54 in SooperLooper::MidiBridge::get_current_host_time (this=0x0) at midi_bridge.cpp:909
909 if (_port) {

Walking "up" the stack in gdb, says it's being called by "SooperLooper::Engine::generate_sync()":
(gdb) up
#1 0x08050ad4 in SooperLooper::Engine::generate_sync (this=0x80d2f48, offset=0, nframes=2048) at engine.cpp:2181
2181 _beatstamp = _midi_bridge->get_current_host_time();

I've no idea about this, but I'm not sure what other information would be useful to address it. I still can't replicate it.

Hi again,

Sorry but I forgot to mention that the segfault I've experienced in v1.6.3 was due to missing libalsa during compile time, causing a missing - and unchecked - MIDI handle to segfault. Now I'm pretty sure that my problem wasn't related to Rog's segfault.

@Rog (initial reporter?)
I've created .deb packages for newer versions of SooperLooper which you could give a try and see if the problem persists - Unfortunately that won't help for the version currently in the repostories. However, you can find sooperlooper packages here:
http://in.das-werkstatt.com/rooker/contribs/packages/sooperlooper/

Unable to reproduce on Lucid.

Karmic has long since stopped to receive any updates. Marking the Karmic task for this ticket as "Won't Fix".