Re: select, jiffies, and SIGALRM

[Vx Glenn <VxGlenn@gmail.com>]

Thanks for the insight. I looked more closely at the trace I have and
I see the POSIX timer is adversely affected by the wrap-around of the
jiffies counter.

getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={2146931,
982728}}) = 0
getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={2146931,
962731}}) = 0
getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={2146931,
962731}}) = 0
getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={131, 601993}}) = 0
getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={131, 601993}}) = 0
getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={131, 601993}}) = 0
getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={131, 599993}}) = 0
getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={131, 599993}}) = 0

And when the SIGALRM fires, the app does not handle it.

My next question is, should the POSIX timer be affected like this? I
guess if it uses the jiffies counter, like everything else, it
probably would.



On Wed, 13 Oct 2004 21:28:26 -0600, Robert Hancock <hancockr@shaw.ca> wrote:
> I see calls to getitimer, so I'm assuming it's also using setitimer. SIGALRM
> is what you get when those timers go off - if it's not handling that, that's
> a bug, but presumably the timer is in there for a reason..
> 
> 
> 
> 
> ----- Original Message -----
> From: "Vx Glenn" <VxGlenn@gmail.com>
> Newsgroups: fa.linux.kernel
> To: <linux-net@vger.kernel.org>; <linux-kernel@vger.kernel.org>
> Sent: Wednesday, October 13, 2004 10:13 AM
> Subject: select, jiffies, and SIGALRM
> 
> > Hi all,
> >
> > I am seeing an issue relating to the jiffies counter wrapping around
> > at 0x7FFFFFFF.
> >
> > This is a legacy application, and when it runs on 32-bit Unix-Like
> > OS's, the application silently dies without leaving core after 248
> > days.
> >
> > I was able to manipulate the jiffies counter and run the application.
> > I was able to reproduce the problem. I captured an strace log, and I
> > see that SIGALRM (alarm clock) is raised after select times out
> > (because of no data).
> >
> > I can add a signal handler to intercept the SIGALRM. But my question
> > is, why should the signal be raised?
> >
> > ---[ strace.log ]---
> > select(1024, [3 4 5 6], NULL, NULL, {0, 320000}) = 0 (Timeout)
> > getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={0, 684895}})
> > = 0
> > adjtimex({modes=32769, offset=0, freq=0, maxerror=16384000,
> > esterror=16384000, status=64, constant=2, precision=1,
> > tolerance=33554432, time={1097551596, 43475}}) = 5
> > getitimer(ITIMER_REAL, {it_interval={2147157, 520}, it_value={0, 684895}})
> > = 0
> > select(1024, [3 4 5 6], NULL, NULL, {1, 0}) = ? ERESTARTNOHAND (To be
> > restarted)
> > --- SIGALRM (Alarm clock) @ 0 (0) ---
> > Process 4881 detached
> > ---[ eof strace.log ]---
> >
> >
> > Anyone have any ideas?
> >
> >
> > --
> > You're not your Job;
> > You're not the contents of your wallet.
> > You're the all singing all dancing crap of the world
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Get Firefox 
http://getfirefox.com