[LAD] Possible jack_port_disconnect() problem.

[Ethan Funk]

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
> writingthrough a FIFO. there's nothing unusual about read(2) showing
> up here - theclient has asked the server for a port disconnect and is
> waiting for aresponse.
> On Tue, Nov 26, 2019 at 9:45 AM Ethan Funk <
> ethan at redmountainradio.com>wrote:
> > After days of testing, I got a crash (of sorts) out of my program.
> > More ofa hang than a crash. So I attached gdb to the process and
> > looked around. Mymain thread appears to be hung deep inside a jack
> > call, viajack_port_disconnect(). This is a point in my code where
> > it cleans up afteran jack-attached media player that is done
> > playing. The player processterminates when it's jack connections
> > are disconnected. I re-started thecode execution and then stopped
> > it again to find that the main thread wasstill waiting at the same
> > libc_read() spot. After taking a look at the jacksource code, I
> > didn't find that jack_port_disconnect() would result in aread any
> > place down the jack call chain. To be fair to jack, I am
> > stillmostly unfamiliar with the library structure, so I could be
> > missingsomething. Any insight as to what I might be doing wrong?
> > The port I ampassing to jack_port_disconnect() appears to be valid,
> > unless my code isoverwriting memory. Backtrace of the main thread
> > is below.
> > Thanks all.Ethan...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-dev/attachments/20191126/05e3cf5b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.linuxaudio.org/archives/linux-audio-dev/attachments/20191126/05e3cf5b/attachment.sig>