Stuck client crashes jackd

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

Stuck client crashes jackd

Glyn Adgie
I am writing a software synth, and driving it from Rosegarden. As I add
new features, I sometimes make a mistake, such that the synth gets stuck
in an endless loop, probably called from the process() callback. After a
few seconds, jackd terminates, which upsets Rosegarden. This means I
have to restart Rosegarden and re-open the Rosegarden score before I can
do more testing.

Is there a Jack callback I should implement that will dump my
misbehaving client in the event of a severe timeout in the process()
callback? It would help a great deal if I had such a thing, so I could
backtrack to the source of the trouble.

A general point: in a many-clients-to-one-server setup, a misbehaving
client should not be able to crash the server, in my opinion. How does
X11 cope with this kind of problem?

--------------

Glyn

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stuck client crashes jackd

Paul Davis
On Tue, 2007-09-25 at 21:40 +0100, Glyn Adgie wrote:

> I am writing a software synth, and driving it from Rosegarden. As I add
> new features, I sometimes make a mistake, such that the synth gets stuck
> in an endless loop, probably called from the process() callback. After a
> few seconds, jackd terminates, which upsets Rosegarden. This means I
> have to restart Rosegarden and re-open the Rosegarden score before I can
> do more testing.
>
> Is there a Jack callback I should implement that will dump my
> misbehaving client in the event of a severe timeout in the process()
> callback? It would help a great deal if I had such a thing, so I could
> backtrack to the source of the trouble.

its not possible to reliably identify which client was responsible for
the crash. remember: control passes from client to client during
process() callbacks, not jack->client->jack->client.

jackd takes a look at the clients in the "chain" of clients that was
being executed, and tries to determine its best guess at who failed.
but ... if one of the clients simply gets stuck, what happens instead is
that the watchdog kicks in a kills everything to avoid a lockup of the
machine.

are you using an explicit client timeout value or not?

> A general point: in a many-clients-to-one-server setup, a misbehaving
> client should not be able to crash the server, in my opinion. How does
> X11 cope with this kind of problem?

interactions between the X server and its clients have very little
resemblance to those between a jack server and its clients.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stuck client crashes jackd

Dmitry Baikov
On 9/26/07, Paul Davis <[hidden email]> wrote:
> its not possible to reliably identify which client was responsible for
> the crash. remember: control passes from client to client during
> process() callbacks, not jack->client->jack->client.
>

Just an idea: before calling process() callback, client-side libjack
can set client PID in the shared mem area, so jackd will always know
who is running now and kill if needed.

Hmm, second later I understood it gives nothing: available time could
be eaten by the previous client, and jack will kill an innocent
(current) one.

Nonetheless, this will help in case of endless loops ;)


Dmitry.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stuck client crashes jackd

cannam
On Wednesday 26 September 2007 09:47, Dmitry Baikov wrote:
> Just an idea: before calling process() callback, client-side libjack
> can set client PID in the shared mem area, so jackd will always know
> who is running now and kill if needed.

Don't forget that under jackdmp, more than one client could be running at the
same time.  (In fact, more than one client could be stuck at the same time.)


Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stuck client crashes jackd

Jack O'Quin
In reply to this post by Glyn Adgie
On 9/25/07, Glyn Adgie <[hidden email]> wrote:

> I am writing a software synth, and driving it from Rosegarden. As I add
> new features, I sometimes make a mistake, such that the synth gets stuck
> in an endless loop, probably called from the process() callback. After a
> few seconds, jackd terminates, which upsets Rosegarden. This means I
> have to restart Rosegarden and re-open the Rosegarden score before I can
> do more testing.
>
> Is there a Jack callback I should implement that will dump my
> misbehaving client in the event of a severe timeout in the process()
> callback? It would help a great deal if I had such a thing, so I could
> backtrack to the source of the trouble.
>
> A general point: in a many-clients-to-one-server setup, a misbehaving
> client should not be able to crash the server, in my opinion. How does
> X11 cope with this kind of problem?

You may want to experiment with configuring JACK using
the little-known --enable-preemption-check option.  This was
added to assist in preemptive kernel development and probably
depends on having an RT patched kernel to do anything useful.

It causes the CHECK_PREEMPTION() macro to generate code
to notify the kernel of the beginning and end of a realtime
critical section before and after calling the client process
handler.  If your kernel supports this system call (an overloaded
version of gettimeofday), it will print the call/return stack if
your program does anything to give up control of the CPU.

If the kernel does not support this extension it will silently
ignore the funny gettimeofday() call.

Of course, this will not trigger if your code just goes into a
loop.  It is only for finding realtime preemption bugs, like
allocating memory inside your process() handler..

For looping, you may be able to set your own private
watchdog timer.  Start it when entering process() and
shut it down when exiting.  If the timer expires, abort
your client process and get a core dump.
--
 joq

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel