on_shutdown issue

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

on_shutdown issue

Rui Nuno Capela
Hi,

I've just stumbled over a probable issue re: client shutdown
notification on jackd >= 0.105.0 (svn).

Incidentally, I'm glad to testify that the return value of the process()
callback is now significantly taken into account. That is, if process()
 returns a non-zero value, and different from the current buffer size,
the jackd server will shutdown the client thread, provoking its
immediate suicide.

Yes, the "offending" client is kicked out from the graph alright. But is
it doing it gracefully? Guess not. Every time that occurs, the entire
jackd service gets frozen and jack_watchdog enters into the scene with
its infamous result: jackd server is also shutdown.

So, first question is: is this a bug, a feature or its finally working
as originally designed ? MHO goes that this on_shutdown logic needs a
fix, at the server control side I mean.

Cheers.
--
rncbc aka Rui Nuno Capela

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: on_shutdown issue

Stéphane Letz

Le 25 mai 07 à 19:28, Rui Nuno Capela a écrit :

> Hi,
>
> I've just stumbled over a probable issue re: client shutdown
> notification on jackd >= 0.105.0 (svn).
>
> Incidentally, I'm glad to testify that the return value of the  
> process()
> callback is now significantly taken into account. That is, if  
> process()
>  returns a non-zero value, and different from the current buffer size,
> the jackd server will shutdown the client thread, provoking its
> immediate suicide.
>
> Yes, the "offending" client is kicked out from the graph alright.  
> But is
> it doing it gracefully? Guess not. Every time that occurs, the entire
> jackd service gets frozen and jack_watchdog enters into the scene with
> its infamous result: jackd server is also shutdown.
>
> So, first question is: is this a bug, a feature or its finally working
> as originally designed ? MHO goes that this on_shutdown logic needs a
> fix, at the server control side I mean.
>
> Cheers.
> --
> rncbc aka Rui Nuno Capela
>

In case it helps, I just added a "callback exiting test" in  
jack_test, the jack API testing code that is part of jackdmp source  
code (file jack_test.cpp in trunk/jackmp/tests)

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: on_shutdown issue

Fernando Lopez-Lezcano
In reply to this post by Rui Nuno Capela
On Fri, 2007-05-25 at 18:28 +0100, Rui Nuno Capela wrote:

> Hi,
>
> I've just stumbled over a probable issue re: client shutdown
> notification on jackd >= 0.105.0 (svn).
>
> Incidentally, I'm glad to testify that the return value of the process()
> callback is now significantly taken into account. That is, if process()
>  returns a non-zero value, and different from the current buffer size,
> the jackd server will shutdown the client thread, provoking its
> immediate suicide.
>
> Yes, the "offending" client is kicked out from the graph alright. But is
> it doing it gracefully? Guess not. Every time that occurs, the entire
> jackd service gets frozen and jack_watchdog enters into the scene with
> its infamous result: jackd server is also shutdown.
>
> So, first question is: is this a bug, a feature or its finally working
> as originally designed ? MHO goes that this on_shutdown logic needs a
> fix, at the server control side I mean.

I'm seeing something similar with 0.107.2.

A client will get kicked out, the whole thing freezes (ie: qjackctl,
etc), the watchdog kicks in and the whole thing, server and clients,
dies.

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: on_shutdown issue

Fernando Lopez-Lezcano
On Fri, 2007-06-15 at 17:34 -0700, Fernando Lopez-Lezcano wrote:

> On Fri, 2007-05-25 at 18:28 +0100, Rui Nuno Capela wrote:
> > Hi,
> >
> > I've just stumbled over a probable issue re: client shutdown
> > notification on jackd >= 0.105.0 (svn).
> >
> > Incidentally, I'm glad to testify that the return value of the process()
> > callback is now significantly taken into account. That is, if process()
> >  returns a non-zero value, and different from the current buffer size,
> > the jackd server will shutdown the client thread, provoking its
> > immediate suicide.
> >
> > Yes, the "offending" client is kicked out from the graph alright. But is
> > it doing it gracefully? Guess not. Every time that occurs, the entire
> > jackd service gets frozen and jack_watchdog enters into the scene with
> > its infamous result: jackd server is also shutdown.
> >
> > So, first question is: is this a bug, a feature or its finally working
> > as originally designed ? MHO goes that this on_shutdown logic needs a
> > fix, at the server control side I mean.
>
> I'm seeing something similar with 0.107.2.
>
> A client will get kicked out, the whole thing freezes (ie: qjackctl,
> etc), the watchdog kicks in and the whole thing, server and clients,
> dies.

This is what "jackd -R -v -d alsa -d hw" has to say just before
everything dies:

---
........
removing disconnected client Traverso state = Running errors = 0
removing client "Traverso"
removing client "Traverso" from the processing chain
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client bitmeter-4695: start_fd=5, execution_order=0.
client fmit: in subgraph after bitmeter-4695, execution_order=1.
client bitmeter-4695: wait_fd=14, execution_order=2 (last client).
-- jack_rechain_graph()
load = 1.6049 max usecs: 351.000, spare = 20982.000
load = 3.1041 max usecs: 982.000, spare = 20351.000
load = 2.3536 max usecs: 342.000, spare = 20991.000
load = 2.0135 max usecs: 357.000, spare = 20976.000
load = 2.0943 max usecs: 464.000, spare = 20869.000
load = 1.5300 max usecs: 206.000, spare = 21127.000
load = 1.2291 max usecs: 198.000, spare = 21135.000
load = 1.1348 max usecs: 222.000, spare = 21111.000
load = 1.8448 max usecs: 545.000, spare = 20788.000
load = 1.4263 max usecs: 215.000, spare = 21118.000
load = 1.2264 max usecs: 219.000, spare = 21114.000
load = 1.0984 max usecs: 207.000, spare = 21126.000
load = 1.0578 max usecs: 217.000, spare = 21116.000
load = 1.0633 max usecs: 228.000, spare = 21105.000
load = 1.0426 max usecs: 218.000, spare = 21115.000
load = 1.0627 max usecs: 231.000, spare = 21102.000
load = 1.0470 max usecs: 220.000, spare = 21113.000
subgraph starting at bitmeter-4695 timed out (subgraph_wait_fd=14,
status = 0, state = Running)
at 19859998116 waiting on 14 for 21589 usecs, status = 1 sig =
19859976509 awa = 19859976548 fin = 19859976570 dur=61
client bitmeter-4695 error: awake_at = 19859976548 state = 2 timed_out =
2
client failure: client bitmeter-4695 state = Running errors = 1
removing client "bitmeter-4695" from the processing chain
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client fmit: start_fd=5, execution_order=0.
jackd watchdog: timeout - killing jackd
Aborted
----

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: on_shutdown issue

Fernando Lopez-Lezcano
On Fri, 2007-06-15 at 17:42 -0700, Fernando Lopez-Lezcano wrote:

> On Fri, 2007-06-15 at 17:34 -0700, Fernando Lopez-Lezcano wrote:
> > On Fri, 2007-05-25 at 18:28 +0100, Rui Nuno Capela wrote:
> > > Hi,
> > >
> > > I've just stumbled over a probable issue re: client shutdown
> > > notification on jackd >= 0.105.0 (svn).
> > >
> > > Incidentally, I'm glad to testify that the return value of the process()
> > > callback is now significantly taken into account. That is, if process()
> > >  returns a non-zero value, and different from the current buffer size,
> > > the jackd server will shutdown the client thread, provoking its
> > > immediate suicide.
> > >
> > > Yes, the "offending" client is kicked out from the graph alright. But is
> > > it doing it gracefully? Guess not. Every time that occurs, the entire
> > > jackd service gets frozen and jack_watchdog enters into the scene with
> > > its infamous result: jackd server is also shutdown.
> > >
> > > So, first question is: is this a bug, a feature or its finally working
> > > as originally designed ? MHO goes that this on_shutdown logic needs a
> > > fix, at the server control side I mean.
> >
> > I'm seeing something similar with 0.107.2.
> >
> > A client will get kicked out, the whole thing freezes (ie: qjackctl,
> > etc), the watchdog kicks in and the whole thing, server and clients,
> > dies.
>
> This is what "jackd -R -v -d alsa -d hw" has to say just before
> everything dies:
>
> ---
> ........
> removing disconnected client Traverso state = Running errors = 0
> removing client "Traverso"
> removing client "Traverso" from the processing chain
> ++ jack_rechain_graph():
> client alsa_pcm: internal client, execution_order=0.
> client bitmeter-4695: start_fd=5, execution_order=0.
> client fmit: in subgraph after bitmeter-4695, execution_order=1.
> client bitmeter-4695: wait_fd=14, execution_order=2 (last client).
> -- jack_rechain_graph()
> load = 1.6049 max usecs: 351.000, spare = 20982.000
> load = 3.1041 max usecs: 982.000, spare = 20351.000
> load = 2.3536 max usecs: 342.000, spare = 20991.000
> load = 2.0135 max usecs: 357.000, spare = 20976.000
> load = 2.0943 max usecs: 464.000, spare = 20869.000
> load = 1.5300 max usecs: 206.000, spare = 21127.000
> load = 1.2291 max usecs: 198.000, spare = 21135.000
> load = 1.1348 max usecs: 222.000, spare = 21111.000
> load = 1.8448 max usecs: 545.000, spare = 20788.000
> load = 1.4263 max usecs: 215.000, spare = 21118.000
> load = 1.2264 max usecs: 219.000, spare = 21114.000
> load = 1.0984 max usecs: 207.000, spare = 21126.000
> load = 1.0578 max usecs: 217.000, spare = 21116.000
> load = 1.0633 max usecs: 228.000, spare = 21105.000
> load = 1.0426 max usecs: 218.000, spare = 21115.000
> load = 1.0627 max usecs: 231.000, spare = 21102.000
> load = 1.0470 max usecs: 220.000, spare = 21113.000
> subgraph starting at bitmeter-4695 timed out (subgraph_wait_fd=14,
> status = 0, state = Running)
> at 19859998116 waiting on 14 for 21589 usecs, status = 1 sig =
> 19859976509 awa = 19859976548 fin = 19859976570 dur=61
> client bitmeter-4695 error: awake_at = 19859976548 state = 2 timed_out =
> 2
> client failure: client bitmeter-4695 state = Running errors = 1
> removing client "bitmeter-4695" from the processing chain
> ++ jack_rechain_graph():
> client alsa_pcm: internal client, execution_order=0.
> client fmit: start_fd=5, execution_order=0.
> jackd watchdog: timeout - killing jackd
> Aborted
> ----

No comments on this?? It is repeatable and I don't think it has to do
with the way the package is being compiled.

A client timeout seems to bring down the server every time through the
watchdog. Hardly usable. Maybe there's a thread somewhere on this which
I missed?

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: on_shutdown issue

Rui Nuno Capela
Fernando Lopez-Lezcano wrote:

> On Fri, 2007-06-15 at 17:42 -0700, Fernando Lopez-Lezcano wrote:
>> On Fri, 2007-05-25 at 18:28 +0100, Rui Nuno Capela wrote:
>>> Hi,
>>>
>>> I've just stumbled over a probable issue re: client shutdown
>>> notification on jackd >= 0.105.0 (svn).
>>>
>>> Incidentally, I'm glad to testify that the return value of the process()
>>> callback is now significantly taken into account. That is, if process()
>>>  returns a non-zero value, and different from the current buffer size,
>>> the jackd server will shutdown the client thread, provoking its
>>> immediate suicide.
>>>
>>> Yes, the "offending" client is kicked out from the graph alright. But is
>>> it doing it gracefully? Guess not. Every time that occurs, the entire
>>> jackd service gets frozen and jack_watchdog enters into the scene with
>>> its infamous result: jackd server is also shutdown.
>>>
>>> So, first question is: is this a bug, a feature or its finally working
>>> as originally designed ? MHO goes that this on_shutdown logic needs a
>>> fix, at the server control side I mean.
>> I'm seeing something similar with 0.107.2.
>>
>> A client will get kicked out, the whole thing freezes (ie: qjackctl,
>>> etc), the watchdog kicks in and the whole thing, server and clients,
>> dies.
>
> ...
>
> No comments on this?? It is repeatable and I don't think it has to do
> with the way the package is being compiled.
>
> A client timeout seems to bring down the server every time through the
> watchdog. Hardly usable. Maybe there's a thread somewhere on this which
> I missed?
>

I believe this is a jackd server issue. As said on my earlier post, this
started on 0.105.0. I can't certify which svn rev. atm, but IIRC that
was one of Paul's "big" revisions, suspiciously the same one which port
name aliases were also introduced.

Bye now.
--
rncbc aka Rui Nuno Capela
[hidden email]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel