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@xxxxxxx> 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@xxxxxxxxx>
Newsgroups: fa.linux.kernel
To: <linux-net@xxxxxxxxxxxxxxx>; <linux-kernel@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/