26 Apr
2003
26 Apr
'03
9:55 p.m.
What does it mean when it says "zombified -- exiting from JACK". Why
exactly is it becoming a zomby or what does it mean and, how do I
reconnect if it does that? It seems to do it intermittently without any
clue why it does it.
Thanks
27 Apr
27 Apr
2:53 p.m.
What does it mean when it says "zombified --
exiting from JACK". Why
exactly is it becoming a zomby or what does it mean and, how do I
reconnect if it does that? It seems to do it intermittently without any
clue why it does it.
first: wrong list. please use jackit-devel.
second: JACK is a realtime system. when its clients do not keep up, it
has no option but to disconnect them from its processing "graph". when
a client is still registered but is no longer part of the graph, we
consider a "zombie".
to avoid this, your program needs to ensure that it meets the
requirement of being real-time safe. see the comments in jack.h
accompanying the jack_set_process_callback() function.
--p
7:01 p.m.
to avoid this, your program needs to ensure that it meets the
requirement of being real-time safe. see the comments in jack.h
accompanying the jack_set_process_callback() function.
Gracias, I found the issue. I had added a pthread_mutex_lock into it
recently inside the callback function. This will be tricky to fix it and
not use a mutex, but that is most likely the problem.
28 Apr
28 Apr
1:49 a.m.
Nick Tsocanos <nicktsocanos(a)charter.net> writes:
The problem, of course, is that the process() function must not wait.
Perhaps you can find a way to use pthread_mutex_trylock(), instead.
--
Jack O'Quin
Austin, Texas, USA
to avoid this, your program needs to ensure that it meets the
requirement of being real-time safe. see the comments in jack.h
accompanying the jack_set_process_callback() function.
Gracias, I found the issue. I had added a pthread_mutex_lock into it
recently inside the callback function. This will be tricky to fix it and
not use a mutex, but that is most likely the problem.
4:49 a.m.
The problem, of course, is that the process() function
must not wait.
Perhaps you can find a way to use pthread_mutex_trylock(), instead.
--
That's actually how I was doing it. For some reason even trylock seemed
to time out. I have not got any zomby messages since than, but I have
not been running it for a length of time at the moment because I am
heavily working on something right now and testing it's functionality.
The zomby would happen intermittently without any clue why. It *seemed*
to have something to do when I used LADSPA plugins, and it was the
LADSPA plugin code that used pthread_mutex functions. This is because
it is possible to alter the list from the GUI thread while the audio
thread is running, and if it were to switch back to the audio thread and
the list had been altered at that point it would crash obviously because
the pointer had been invalidated.
Since I changed it it has not given me a zomby message yet.
I will run it for a while to see if it becomes a zomby again. Only time
will tell.
9:15 a.m.
A not to closely related observation i made with ams:
if i am running ams and qjackconnect, the jack thread in ams "zombifies"
reproducable whenever i quit qjackconnect.
I didn't spend much time in investigation of this so far.
What subtile relationship between the two clients could be responsible
for this?
Seems i will have to dive into ams's jack code again.
Regards,
Lukas
9:54 a.m.
On Mon, 28 Apr 2003, Lukas Degener wrote:
A not to closely related observation i made with ams:
if i am running ams and qjackconnect, the jack thread in ams "zombifies"
reproducable whenever i quit qjackconnect.
One bug that caused this behaviour was just fixed (26.4.) in
JACK's CVS-tree.
--
http://www.eca.cx
Audio software for Linux!
7875
days inactive
7877
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Jack O'Quin -
Kai Vehmanen -
Lukas Degener -
Nick Tsocanos -
Paul Davis