stopRecording crashes supernova

[jamshark70]

Server.supernova;
s.boot;
s.record;

// wait
s.stopRecording;

With .dumpOSC on the last command:

received osc message [11 int32:1000]
Recording Stopped: nil
-> localhost
received osc message [/b_close int32:1025, OSC-blob:<<0x2f 0x62 0x5f 0x66 0x72 0x65 0x65 0x00 0x2c 0x69 0x69 0x00 0x00 0x00 0x04 0x01 0x00 0x00 0x00 0x00>>]
RESULT = 0

Synth is freed, buffer is closed and then freed ("OSC-blob"), but supernova dies.

I could recover my recording by importing raw into Audacity, but... man, can't record cleanly? This is a bad bad bug.

[jamshark70]

gdb says:

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7fffe7931700 (LWP 16961)]
0x00007ffff72fc244 in sf_writef_float ()
   from /usr/lib/x86_64-linux-gnu/libsndfile.so.1
(gdb) where
#0  0x00007ffff72fc244 in sf_writef_float ()
   from /usr/lib/x86_64-linux-gnu/libsndfile.so.1
#1  0x00007fffe793541c in (anonymous namespace)::DiskIOMsg::Perform (
    this=0x7fffe78f0da0)
    at /home/dlm/share/sc-hjh.git/server/plugins/DiskIO_UGens.cpp:152
#2  0x00007fffe793568e in (anonymous namespace)::DiskIOThread::ioThreadFunc (
    this=0xcc1400)
    at /home/dlm/share/sc-hjh.git/server/plugins/DiskIO_UGens.cpp:211
#3  0x00007fffe793a805 in std::_Mem_fn<void ((anonymous namespace)::DiskIOThread::*)()>::operator()<, void>((anonymous namespace)::DiskIOThread *) const (
    this=0xcb5fa0, __object=0xcc1400) at /usr/include/c++/4.8/functional:601
#4  0x00007fffe793a76a in std::_Bind<std::_Mem_fn<void ((anonymous namespace)::DiskIOThread::*)()>((anonymous namespace)::DiskIOThread*)>::__call<void, 0ul>(<unknown type in /usr/local/lib/SuperCollider/plugins/DiskIO_UGens_supernova.so, CU 0x0, DIE 0x12b22>, std::_Index_tuple<0ul>) (this=0xcb5fa0, 
    __args=<unknown type in /usr/local/lib/SuperCollider/plugins/DiskIO_UGens_supernova.so, CU 0x0, DIE 0x12b22>) at /usr/include/c++/4.8/functional:1296
#5  0x00007fffe793a6e9 in std::_Bind<std::_Mem_fn<void ((anonymous namespace)::DiskIOThread::*)()>((anonymous namespace)::DiskIOThread*)>::operator()<, void>(void) (this=0xcb5fa0) at /usr/include/c++/4.8/functional:1355
#6  0x00007fffe793a678 in std::_Bind_simple<std::_Bind<std::_Mem_fn<void ((anonymous namespace)::DiskIOThread::*)()>((anonymous namespace)::DiskIOThread*)>()>::_M_invoke<>(std::_Index_tuple<>) (this=0xcb5fa0)
    at /usr/include/c++/4.8/functional:1732
#7  0x00007fffe793a5cf in std::_Bind_simple<std::_Bind<std::_Mem_fn<void ((anonymous namespace)::DiskIOThread::*)()>((anonymous namespace)::DiskIOThread*)>()>::operator()(void) (this=0xcb5fa0) at /usr/include/c++/4.8/functional:1720
#8  0x00007fffe793a564 in std::thread::_Impl<std::_Bind_simple<std::_Bind<std::_Mem_fn<void ((anonymous namespace)::DiskIOThread::*)()>((anonymous namespace)::DiskIOThread*)>()> >::_M_run(void) (this=0xcb5f88)
    at /usr/include/c++/4.8/thread:115
---Type <return> to continue, or q <return> to quit---
#9  0x00007ffff6a639c0 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00007ffff79bf184 in start_thread (arg=0x7fffe7931700)
    at pthread_create.c:312
#11 0x00007ffff61eb37d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[jamshark70]

Possible workaround in the classlib (tested, no crash):

1. Free the recording synth.
2. WAIT.
3. Close and free the buffer.

Currently we don't wait, so the record synth might be using the buffer at the time of freeing it.

But supernova should not rely on the client to tiptoe around its bugs. Better to make it not crash.

[vivid-synth]

Ouch, is this true for any synth which tries to read from a Buffer that's been freed? (This is partly a note to myself to test this later)

[jamshark70]

Duplicate of #1515. I swear I searched for existing bugs but github didn't show me anything. Grr.

[telephon]

can you try if this fixes it? I am not sure …

[jamshark70]

I can try in a few days. I'm finalizing a piece for a Tuesday concert, and I'm not changing anything in my environment until that's over (esp. larger changes like the server-refactor branch).

I am not sure of the timing relationship between synchronous commands (n_free) and asynchronous ones (b_close, b_free). Hm, I was going to say that bundling probably wouldn't fix it, but on second thought, it might guarantee that the buffer operations enter the sequenced command queue after the n_free is done.

Or command scheduling might be different in supernova, in which case, I have no idea.

[jamshark70]

Ouch, is this true for any synth which tries to read from a Buffer that's been freed?

I believe it'll be specific to DiskOut.

[telephon]

yes, check it any time you can. I was thinking that if this one fixes it, it would make sense. If it doesn't fix it, the issue is a little more general and fixing it in ServerStatusWatcher would feel more like a workaround than a good solution. But even then it would be easy to do of course.

[telephon]

(ping - still there?)

[nhthn]

If this is still happening, I think it should be high priority for 3.9.

[adcxyz]

On macOS, current develop branch, this works

• @jamshark70, can you test on linux/windows?

  
  s.quit; Server.supernova;

s.waitForBoot { s.record; 0.5.wait; ().play; 1.5.wait; // wait s.stopRecording; 0.5.wait; // newest file should be 2 secs soundfile with 2 Platform.recordingsDir.openOS };

[telephon]

closing for now, please reopen if it still happens