sooperlooper crashes when record hits end of loop mem time

[sireasoning]

I am running linux and version 1.6.14, using jack 1.9.4 and ffado-2.0-svn while using a MOTU 896HD firewire device.

I have run across a problem that seems to be consistent. I default to having 6 stereo loops.
In this session I have 2 loops recorded and was working on the 3rd loop having all three loops with the sync button and loop2 and loop3 with the "play sync" activated. Quantize is set to loop and sync to loop1.
When I hit the record button it generally waits to start recording until the playing loop restarts, then if I hit the record button again, it would stop recording when loop1 ended. However, if I keep recording past that spot then tap the record button, then it will continue recording until it hits the end of the preset memory which is at 43.69 seconds. Unfortunately if the later happens, sooperlooper crashes and has to be restarted (with all data from that session lost unless it was saved prior to the crash.) This has happened to me twice in a row.

[sireasoning]

If I go past the end of loop1 while recording in loop3 before hitting the record button a 2nd time as described previously, and then try to hit "undo" it still causes the system to crash. However if I hit the record button before loop1 has hit the end of the loop, it works fine.

[sireasoning]

More info on how SooperLooper crashes as described above:
After what I described above happens, its connection to Jack ends abruptly which then causes SooperLooper to disappear. Jack however still works and I just have to start SooperLooper again and it will reconnect with Jack.

[sireasoning]

This appears to be a jack issue, it is now showing up in other programs.

[sireasoning]

although I don't know if we can say it is completely jack as it happens consistently if I follow the steps described above. I have not found out any other issues with jack being dropped with sooperlooper (not yet at least.)

[sireasoning]

I have also been working with the MOTU 896HD driver maintainer with ffado and am trying to work with jack-devel on this. The 896HD maintainer after looking at my logs, and some discussion and research does not believe it is a ffado issue. I would highly encourage a sooperlooper developer to join in on this discussion on the jack-devel mailing list. The discussion can be found under the following thread:
Jack-Devel] Jack2 drops from several programs causing them to either crash or interrupt until reconnected with jack

[jesse]

Sorry, I've been a bit out of the loop here in SL land. I will try to reproduce your issue independently...

If you could set up the following to help me diagnose it, it might help: run the sooperlooper engine separately from slgui in a terminal, and run it in gdb.

$ gdb sooperlooper
(gdb) run

===

Then start the gui somewhere else. Try to reproduce your issue and make it crash. When it does, in gdb do:

(gdb) thread apply all bt

And paste the entire results of that.

Thanks!

[sireasoning]

(gdb) thread apply all bt

Thread 7 (Thread 0x7fffebf43910 (LWP 3207)):
#0 0x00007ffff5f0c412 in select () from /lib/libc.so.6
#1 0x000000000044188a in SooperLooper::MidiBridge::clock_thread_entry (
this=0xbccdd0) at midi_bridge.cpp:745
#2 0x00007ffff777ba04 in start_thread () from /lib/libpthread.so.0
#3 0x00007ffff5f1380d in clone () from /lib/libc.so.6
#4 0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7fffec744910 (LWP 3206)):
#0 0x00007ffff5f073c3 in poll () from /lib/libc.so.6
#1 0x0000000000442fa0 in SooperLooper::MidiBridge::midi_receiver (
this=0xbccdd0) at midi_bridge.cpp:643
#2 0x00000000004430a3 in SooperLooper::MidiBridge::_midi_receiver (
arg=0x7fffec743e80) at midi_bridge.cpp:617
#3 0x00007ffff777ba04 in start_thread () from /lib/libpthread.so.0
#4 0x00007ffff5f1380d in clone () from /lib/libc.so.6
#5 0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7fffee875910 (LWP 3205)):
#0 0x000000000043d241 in runSooperLooper (Instance=0x2480b10,
SampleCount=<value optimized out>) at plugin.cc:3341
#1 0x0000000000434778 in SooperLooper::Looper::run_loops (this=0x1eb3070,
---Type <return> to continue, or q <return> to quit---
offset=<value optimized out>, nframes=<value optimized out>)
at looper.cpp:1357
#2 0x00000000004351d7 in SooperLooper::Looper::run (this=0x1eb3070, offset=0,
nframes=512) at looper.cpp:1058
#3 0x000000000040ee4e in SooperLooper::Engine::process (this=0x67f2f0,
nframes=512) at engine.cpp:910
#4 0x00000000004098b4 in SooperLooper::JackAudioDriver::process_callback (
this=<value optimized out>, nframes=38966720) at jack_audio_driver.cpp:228
#5 0x00007ffff7babfea in Jack::JackClient::CallProcessCallback (this=0x68bf00)
at ../common/JackClient.cpp:445
#6 Jack::JackClient::ExecuteThread (this=0x68bf00)
at ../common/JackClient.cpp:412
#7 Jack::JackClient::Execute (this=0x68bf00) at ../common/JackClient.cpp:397
#8 0x00007ffff7bc3f70 in Jack::JackPosixThread::ThreadHandler (
arg=<value optimized out>) at ../posix/JackPosixThread.cpp:59
#9 0x00007ffff777ba04 in start_thread () from /lib/libpthread.so.0
#10 0x00007ffff5f1380d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7ffff129d910 (LWP 3204)):
#0 0x00007ffff5f073c3 in poll () from /lib/libc.so.6
#1 0x0000000000422e3c in SooperLooper::ControlOSC::osc_receiver (
this=0x6c1990) at control_osc.cpp:444
---Type <return> to continue, or q <return> to quit---
#2 0x0000000000422cc0 in SooperLooper::ControlOSC::_osc_receiver (
arg=0x6c1990) at control_osc.cpp:404
#3 0x00007ffff777ba04 in start_thread () from /lib/libpthread.so.0
#4 0x00007ffff5f1380d in clone () from /lib/libc.so.6
#5 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7ffff4abd910 (LWP 3203)):
#0 0x00007ffff77830cb in read () from /lib/libpthread.so.0
#1 0x00007ffff7bc5e22 in read (this=0x68c340, data=0x7ffff4abcf40, len=65)
at /usr/include/bits/unistd.h:45
#2 Jack::JackClientSocket::Read (this=0x68c340, data=0x7ffff4abcf40, len=65)
at ../posix/JackSocket.cpp:183
#3 0x00007ffff7bc85c4 in Jack::JackClientNotification::Read (this=0x68c0b0)
at ../common/JackRequest.h:1095
#4 Jack::JackSocketClientChannel::Execute (this=0x68c0b0)
at ../posix/JackSocketClientChannel.cpp:317
#5 0x00007ffff7bc3f70 in Jack::JackPosixThread::ThreadHandler (
arg=<value optimized out>) at ../posix/JackPosixThread.cpp:59
#6 0x00007ffff777ba04 in start_thread () from /lib/libpthread.so.0
#7 0x00007ffff5f1380d in clone () from /lib/libc.so.6
#8 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7ffff7ec3910 (LWP 3186)):
---Type <return> to continue, or q <return> to quit---
#0 0x00007ffff77805a9 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#1 0x00007ffff7bc5a81 in Jack::JackProcessSync::Wait (
this=<value optimized out>) at ../posix/JackProcessSync.cpp:69
#2 0x00007ffff7bbebc9 in Jack::JackMessageBuffer::Execute (this=0x683b20)
at ../common/JackMessageBuffer.cpp:84
#3 0x00007ffff7bc3f70 in Jack::JackPosixThread::ThreadHandler (
arg=<value optimized out>) at ../posix/JackPosixThread.cpp:59
#4 0x00007ffff777ba04 in start_thread () from /lib/libpthread.so.0
#5 0x00007ffff5f1380d in clone () from /lib/libc.so.6
#6 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7ec4710 (LWP 3183)):
#0 0x00007ffff778082d in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#1 0x000000000041204a in SooperLooper::Engine::mainloop (this=0x67f2f0)
at engine.cpp:1630
#2 0x0000000000408b79 in main (argc=1, argv=0x7fffffffe788)
at sooperlooper.cpp:381

[sireasoning]

Further refining:
It seems to be an issue with quantize when it hits the end of the mem time limit.

Also, there is another issue with the mem time limit in that if quantize is not active, then when it hits the end of the mem time limit it will show on the screen that it has stopped recording and is "playing" back but no sound comes through the speakers until I hit trigger and then for whatever time it had been "playing back" it was actually overdubbing (and I can hear it all through the speakers again.)

[jesse]

OK, can you also save off a session with all the settings you used to reproduce the crashing issue?

In the meantime, raise the max loop time in the preferences or by using add custom loop! Memory is cheap. I think all of these cases are when it hits the limit of a single loop length. If you raise the max mem for each loop beyond (preferably > 2x) your predicted max length, you won't have to worry about these issues.