callback mode doesn't work

[ul]

Trying to select callback option I get “./noise” terminated by signal SIGSEGV (Address boundary error)
Blocking mode works fine.

[jordwalke]

Did anyone ever figure out what was going on here?

[smimram]

I cannot reproduce here. A gdb stacktrace would be quite useful...

[jordwalke]

I don't think it gives a stack trace. It just prints that SIGSEGV message. Can you refresh my memory about how to get a stack trace on SIGSEGV?

[smimram]

You should run

gdb ./noise

then run to run the program and then bt to get a backtrace when it crashes.

[samer--]

Hi, I'm also getting the segfault using callback mode. Here is the stack trace from gdb:

Thread 9 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x290f of process 46335]
0x0000000100046139 in caml_thread_leave_blocking_section ()
(gdb) bt
#0  0x0000000100046139 in caml_thread_leave_blocking_section ()
#1  0x0000000100050cb3 in caml_leave_blocking_section () at signals.c:167
#2  0x00000001000438fc in pa_callback (input_buffer=0x0, output_buffer=0x100891800, frames_per_buffer=4096, time_info=0x150000001601, status_flags=4295743352, user_data=0x0) at portaudio_stubs.c:280
#3  0x00000001001f3849 in AdaptingOutputOnlyProcess () from /opt/local/lib/libportaudio.2.dylib
#4  0x00000001001f2b94 in PaUtil_EndBufferProcessing () from /opt/local/lib/libportaudio.2.dylib
#5  0x00000001001f7ac8 in AudioIOProc () from /opt/local/lib/libportaudio.2.dylib
#6  0x000000010545d4e8 in AUConverterBase::RenderBus(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int) () from /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
#7  0x0000000105587c54 in AUBase::DoRenderBus(unsigned int&, AudioTimeStamp const&, unsigned int, AUOutputElement*, unsigned int, AudioBufferList&) ()
   from /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
#8  0x000000010558732a in AUBase::DoRender(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int, AudioBufferList&) () from /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
#9  0x0000000105460fb4 in AUHAL::AUIOProc(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) ()
   from /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
#10 0x00007fff381c1825 in HALC_ProxyIOContext::IOWorkLoop() () from /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
#11 0x00007fff381c02bc in HALC_ProxyIOContext::IOThreadEntry(void*) () from /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
#12 0x00007fff381bfffe in HALB_IOThread::Entry(void*) () from /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
#13 0x00007fff60a5a661 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
#14 0x00007fff60a5a50d in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
#15 0x00007fff60a59bf9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
#16 0x0000000000000000 in ?? ()

[samer--]

I'm using portaudio and opam from Macports, and ocaml 4.09.0 from opam. I am able to use portaudio callback mode from Python using both the PyAudio and SoundDevice packages, so I think the portaudio is ok.

[samer--]

Just to expand further on this, if it helps at all, I found the following comment here [https://lwn.net/Articles/183943/]

   For callbacks from C code you will typically first call
   leave_blocking_section() and later enter_blocking_section()
   before you return.

- O'Caml must never see threads not created by itself. This
   means a thread created by your middleware must not run
   O'Caml code. (You get immediately a segfault if you try.)

And later:

> However, let's make it clearer, you can create a thread in ocaml and then
 > call a C function, and this C function, which will be run concurrently with
 > other C functions called the same way, can call back ocaml.

Yes, this is possible, and good libraries provide ways of letting user
created threads enter the library to execute callbacks.

Judging from the portaudio documentation, the callback thread can come from the guts of the system and the caller has no way to control this, so perhaps this is what the problem is?