Related question then: Any idea what my application could be doing wrong to cause jack to not get back with a response? It had been waiting for about an hour, while I was off doing paying work, and my applications process function was still being called by jack when I finally noticed it. My best plan for now is to test again, and wait for it to happen, then see if I can get another jack program to connect/disconnect after my program hangs, and check the jack logs right away. The jack log file from this test is full of underruns from my debugging, so that is mostly useless. Any other debuging approach I should be taking?

Thanks,
Ethan...

On Tue, 2019-11-26 at 10:10 -0700, Paul Davis wrote:
jack clients and the server on linux communicate via reading and writing
through a FIFO. there's nothing unusual about read(2) showing up here - the
client has asked the server for a port disconnect and is waiting for a
response.

On Tue, Nov 26, 2019 at 9:45 AM Ethan Funk <
ethan@redmountainradio.com
>
wrote:

After days of testing, I got a crash (of sorts) out of my program. More of
a hang than a crash. So I attached gdb to the process and looked around. My
main thread appears to be hung deep inside a jack call, via
jack_port_disconnect(). This is a point in my code where it cleans up after
an jack-attached media player that is done playing. The player process
terminates when it's jack connections are disconnected. I re-started the
code execution and then stopped it again to find that the main thread was
still waiting at the same libc_read() spot. After taking a look at the jack
source code, I didn't find that jack_port_disconnect() would result in a
read any place down the jack call chain. To be fair to jack, I am still
mostly unfamiliar with the library structure, so I could be missing
something. Any insight as to what I might be doing wrong? The port I am
passing to jack_port_disconnect() appears to be valid, unless my code is
overwriting memory. Backtrace of the main thread is below.

Thanks all.
Ethan...