[Jack-Devel] BUG REPORT : Overflow of XRUNs after a certain time

Symptoms : After a certain amount of time running troublefree and xrun-free 
the jack daemon, the qjackctl interface starts reporting an always increasing 
number of xruns while the desktop becomes more or less unresponsive.
==========
Reproduceable : Always and irrespective of the number of clients registred
==========
System : All Linux kernels from 2.6.34 (at least) up to 3.2 (included)
Jack : All Jack legacy versions from 0.118.0 up to 0.121.3 (included)
Audio device : ICE1712 driven M-Audio-Audiophile-24-96
Jack daemon started as :
jackd -R -P89 -dalsa -r44100 -p512 -n2 -D -Chw:2 -Phw:2 -s -Xraw -zs
Or
jackd -P89 -m -dalsa -dhw:3 -r44100 -p256 -n3 -Xraw -P -zs
Or at the extreme limit whatever, it does not seem to depend on the parameters 
apart from, as we will see later on the sampling frequency.
==========
Traces when the problem occurs (no client registred)

23:34:39.236 XRUN callback (1).
delay of 48867.000 usecs exceeds estimated spare time of 11587.000; restart 
...
----- preceeding entry repeated 5 times -------
23:34:40.237 XRUN callback (6).
delay of 38983.000 usecs exceeds estimated spare time of 11579.000; restart 
...
----- preceeding entry repeated 8 times --------
23:34:42.237 XRUN callback (14).
..... And so on ad libitum .....
===========
First level analysis :

Could be a coincidence but I think it is worth to mention :

If the sampling frequency is set to 44100, then the problem occurs after about 
13h 31mn 35s
If the sampling frequency is set to 48000, then the problem occurs after about 
12h 25mn 36s

Something remarkable is that :

0x7FFFFFFF / 44100 ~= 13h 31mn 35s
0x7FFFFFFF / 48000 ~= 12h 25mn 36s

This makes me believe that there is somewhere some signed-long counter of 
samples which obviously overflows.
===============
Note : This bug is not critical under a stock Linux kernel as, even if the 
desktop becomes far less responsive it is still possible to stop jackd via the 
qjackctl interface.
It becomes however critical when running a ck-patched kernel. In this case, 
one cannot even reach the console or trigger the system shutdown by any mean. 
The only solution being to reset the system.

Regards,

aCOSwt 

1337930527.22098_0.ltw:2, <201205250922.20515.acoswt at orange dot fr>