Re: [Jack-Devel] 107.x faults

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

Re: [Jack-Devel] 107.x faults

Pieter Palmers
Rui Nuno Capela wrote:

> Geoff Beasley wrote:
>> Intrigued to know why svn jack has remained so broken for so long without
>> being rectified. it crashes all the time . no mention of it on this list  to
>> speak of.
>>
>> been reported by many luminaries.... Rui & Nando among them
>> eg loading a second Ardour session will cause Ardour to segfault, adding and
>> subtracting clients from the jack graph will kill jack etc.
>>
>> anyway just wondering.
>>
>> very un-jack-like
>>
>
> i have a sure crash test program here (jack_test1.c) for jack >= 0.105.x
> for you play with:
>
>   gcc -o jack_test1 jack_test1.c -ljack
>
> a bit elaborated but it's simply a perfectly legal jack client that
> mixes all its inputs to each one of the outputs, but the case here is
> all about the return value (ret) of the process() callback function.
>
> when started, jack_test1 will run for 30 seconds and then it marks the
> ret value to non-zero. just that will instruct jackd to issue the
> shutdown callback which is also trapped and puts the ret value back to
> zero. the client continues to run; it should have exit()ed in response
> to the shutdown call but that's not the point here.
>
> the point is, after a while, jackd gets frozen and killed by its own
> jack_watchdog. try it as many times as you wish, it always dies
> systematically. bad eh?
OK, your ever lasting subtle complaints pay off on the long run :)...

Attached a patch that should fix your issue. Please test it. It fixes
the test case you posted.

Paul (and others): please review this 20-line patch as it changes the
shared memory structures. What it basically does is add a shared memory
variable that tracks the last process callback return value for external
clients. This allows for the server to detect a nonzero process callback
return value. When such a case is detected, it is considered an error
and is treated as if the client has exited. There might be some
side-effects that I missed, hence I'd like some feedback.

Greets,

Pieter

Index: libjack/client.c
===================================================================
--- libjack/client.c (revision 1070)
+++ libjack/client.c (working copy)
@@ -1199,6 +1199,7 @@
  if (client->on_shutdown) {
  jack_error ("zombified - calling shutdown handler");
  client->on_shutdown (client->on_shutdown_arg);
+
  } else {
  jack_error ("jack_client_thread zombified - exiting from JACK");
  jack_client_close (client);
@@ -1470,20 +1471,20 @@
 jack_nframes_t
 jack_thread_wait (jack_client_t* client, int status)
 {
- jack_client_control_t *control = client->control;
+ client->control->last_status = status;
 
    /* SECTION ONE: HOUSEKEEPING/CLEANUP FROM LAST DATA PROCESSING */
 
  /* housekeeping/cleanup after data processing */
 
- if (status == 0 && control->timebase_cb) {
+ if (status == 0 && client->control->timebase_cb) {
  jack_call_timebase_master (client);
  }
 
  /* end preemption checking */
  CHECK_PREEMPTION (client->engine, FALSE);
 
- control->finished_at = jack_get_microseconds();
+ client->control->finished_at = jack_get_microseconds();
 
  /* wake the next client in the chain (could be the server),
    and check if we were killed during the process
@@ -1509,15 +1510,15 @@
 
  /* Time to do data processing */
 
- control->state = Running;
+ client->control->state = Running;
 
  /* begin preemption checking */
  CHECK_PREEMPTION (client->engine, TRUE);
 
- if (control->sync_cb)
+ if (client->control->sync_cb)
  jack_call_sync_client (client);
 
- return control->nframes;
+ return client->control->nframes;
 }
 
 static void *
Index: jack/internal.h
===================================================================
--- jack/internal.h (revision 1070)
+++ jack/internal.h (working copy)
@@ -225,6 +225,7 @@
     volatile uint64_t signalled_at;
     volatile uint64_t awake_at;
     volatile uint64_t finished_at;
+    volatile int32_t last_status;         /* w: client, r: engine and client */
 
     /* JOQ: all these pointers are trouble for 32/64 compatibility,
      * they should move to non-shared memory.
Index: jackd/engine.c
===================================================================
--- jackd/engine.c (revision 1070)
+++ jackd/engine.c (working copy)
@@ -2065,11 +2065,19 @@
  client->control->name);
  client->error++;
  }
+ if(client->control->last_status != 0) {
+ VERBOSE(engine,
+ "client %s has nonzero process callback status (%d)\n",
+ client->control->name, client->control->last_status);
+ client->error++;
+ }
  }
 
  DEBUG ("client %s errors = %d", client->control->name,
        client->error);
  }
+
+ //jack_remove_clients (engine);
  }
 
  jack_engine_post_process (engine);

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Jack-Devel] 107.x faults

Rui Nuno Capela
Pieter Palmers wrote:
 > OK, your ever lasting subtle complaints pay off on the long run :)...

>
> Attached a patch that should fix your issue. Please test it. It fixes
> the test case you posted.
>
> Paul (and others): please review this 20-line patch as it changes the
> shared memory structures. What it basically does is add a shared memory
> variable that tracks the last process callback return value for external
> clients. This allows for the server to detect a nonzero process callback
> return value. When such a case is detected, it is considered an error
> and is treated as if the client has exited. There might be some
> side-effects that I missed, hence I'd like some feedback.
>

i've tested the patch and it does seem to solve the process callback
return value issue, in most scenarios that i've briefly tested. didn't
found any side effects.

however, it still fails with the very same behavior when the alsa
playback device is dmix based. but that might just be yet another can of
worms ;)

the patch looks good and i do testify for a recommendation.

Pieter, you're my hero ;)
--
rncbc aka Rui Nuno Capela
[hidden email]
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org