100% cpu loop of time() ...

One perl daemon happens to go sometimes into 100% cpu state.
When I do strace or ltrace on it, I see infinite sequence of time()
calls,
and nothing in between.

But the source code, although has couple of calls to time(), nowhere
has possibility of infinite lop of time(). I wonder whether perl
interpreter can be doing this inside it, maybe restarting on signals
or something ? The code is single-threaded. Wrt to signals, it either
ignores
signals, or dies on signals.

Yakov

Re: 100% cpu loop of time() ...

Quoth Yakov :
> One perl daemon happens to go sometimes into 100% cpu state.
> When I do strace or ltrace on it, I see infinite sequence of time()
> calls,
> and nothing in between.
>
> But the source code, although has couple of calls to time(), nowhere
> has possibility of infinite lop of time(). I wonder whether perl
> interpreter can be doing this inside it, maybe restarting on signals
> or something ? The code is single-threaded. Wrt to signals, it either
> ignores
> signals, or dies on signals.

Are you able to run it with a debugging build of perl, and break in with
a debugger to get a stacktrace?

Ben

Re: 100% cpu loop of time() ...

Yakov wrote:
> One perl daemon happens to go sometimes into 100% cpu state.
> When I do strace or ltrace on it, I see infinite sequence of time()
> calls,
> and nothing in between.
>
> But the source code, although has couple of calls to time(), nowhere
> has possibility of infinite lop of time(). I wonder whether perl
> interpreter can be doing this inside it, maybe restarting on signals
> or something ?

If it were restarting on signals, then the signal events should be evident
in the strace along with the "time" calls.

> The code is single-threaded. Wrt to signals, it either
> ignores
> signals, or dies on signals.

Does it do any forking, either explicit or implicit (implicit meanings
with back-ticks, system, piped open, etc.)

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

Re: 100% cpu loop of time() ...

On Nov 15, 7:06 pm, xhos...@gmail.com wrote:
> Yakov wrote:
> > One perl daemon happens to go sometimes into 100% cpu state.
> > When I do strace or ltrace on it, I see infinite sequence of time()
> > calls,
> > and nothing in between.
>
> > But the source code, although has couple of calls to time(), nowhere
> > has possibility of infinite lop of time(). I wonder whether perl
> > interpreter can be doing this inside it, maybe restarting on signals
> > or something ?
>
> If it were restarting on signals, then the signal events should be evident
> in the strace along with the "time" calls.
>
> > The code is single-threaded. Wrt to signals, it either
> > ignores
> > signals, or dies on signals.
>
> Does it do any forking, either explicit or implicit (implicit meanings
> with back-ticks, system, piped open, etc.)

No. I will try to build debugging build of perl.

Yakov

Re: 100% cpu loop of time() ...

On Nov 18, 2:52 pm, Yakov wrote:
> On Nov 15, 7:06 pm, xhos...@gmail.com wrote:
>
>
>
> > Yakov wrote:
> > > One perl daemon happens to go sometimes into 100% cpu state.
> > > When I do strace or ltrace on it, I see infinite sequence of time()
> > > calls,
> > > and nothing in between.
>
> > > But the source code, although has couple of calls to time(), nowhere
> > > has possibility of infinite lop of time(). I wonder whether perl
> > > interpreter can be doing this inside it, maybe restarting on signals
> > > or something ?
>
> > If it were restarting on signals, then the signal events should be evident
> > in the strace along with the "time" calls.
>
> > > The code is single-threaded. Wrt to signals, it either
> > > ignores
> > > signals, or dies on signals.
>
> > Does it do any forking, either explicit or implicit (implicit meanings
> > with back-ticks, system, piped open, etc.)
>
> No.

I got the pstrack trace. This is still regular build of perl.
Can any useful conclusion or information be extracted from this trace:

0x4008e370: Perl_pp_and (804b3c8, 0, 4010d44d, 4011ebac, 4011ebac,
80dea6c)
0x40036139: S_call_body + 0x39 (804b3c8, bffff990, 0, 4016fc34,
80667a0, 2d8580) + 120
0x40036047: Perl_call_sv + 0x637 (804b3c8, 80dea6c, 2, bffffa00, 0,
23) + 30
0x4007e52e: Perl_vwarner + 0x32e (804b3c8, 29, 40111c60, bffffa30,
bffffa54, 4011ebac)
0x4007e1ea: Perl_warner + 0x3a (804b3c8, 29, 40111c60, 4010e618,
40107a07, 402d8580) + 10
0x40097320: Perl_report_uninit + 0x60 (804b3c8, 85ea160, bffffa98,
4016a012, 402d8590, 30) + c0
0x4009aed1: Perl_sv_2pv_flags + 0x8c1 (804b3c8, 8064e6c, bffffb98, 2,
27, 85c5070) + 40
0x40089ed7: Perl_hv_exists_ent + 0x207 (804b3c8, 8064cec, 8064e6c, 0,
804b3c8, bffffda4) + 20
0x400b615b: Perl_pp_exists + 0x11b (804b3c8, 0, 0, 4008e03a, 4011ebac,
804b3c8)
0x4008e059: Perl_runops_standard + 0x29 (804b3c8, 400125c0, 40012934,
4011ebac, 4011ebac, 40012140)
0x400355bb: S_run_body + 0xeb (804b3c8, 1, 400128e8, 1, 1, 0) + d0
0x40035355: perl_run + 0x165 (804b3c8, 80491c0, 3, bffffda4, 0,
bffffd44) + 10
0x08049173: main + 0xd3 (3, bffffda4, bffffdb4, 402d8108, 0, 40009db0)
+ 10
0x401c554d: _fini + 0xa124d (80490a0, 3, bffffda4, 8048d64, 8049e60,
4000a66c) + 40000268

(No symbols found in /lib/libnsl.so.1)
(No symbols found in /lib/libdl.so.2)
(No symbols found in /lib/libm.so.6)
(No symbols found in /lib/libpthread.so.0)
(No symbols found in /lib/libc.so.6)
(No symbols found in /lib/libcrypt.so.1)
(No symbols found in /lib/libutil.so.1)
(No symbols found in /lib/ld-linux.so.2)
(No symbols found in /lib/libresolv.so.2)
(No symbols found in /lib/libnss_files.so.2)


Yakov