Re: monit deadlocks

[Eli Yukelzon]

what's not to like about cvs? :)
I'll give it a spin and report back.
thanks alot!

On 11/7/05, Martin Pala <address@hidden> wrote:
> Thanks,
>
> current cvs version should solve the problem. Can you test the current
> cvs version? If you don't like cvs, we can prepare snapshot for you.
>
> Thanks,
> Martin
>
>
> Eli Yukelzon wrote:
> > hi there.
> > well, after a week of delay the problem creeped up.
> > here's the gdb output:
> > Thread 2 (Thread -1211012176 (LWP 11591)):
> > #0  0xffffe410 in ?? ()
> > #1  0xb7d16388 in ?? ()
> > #2  0x00000000 in ?? ()
> > #3  0xb7d162f0 in ?? ()
> > #4  0xb7ddc751 in ___newselect_nocancel () from /lib/libc.so.6
> > #5  0x08051532 in can_read (socket=6, timeout=-514) at net.c:475
> > #6  0x08063791 in start_httpd (port=2812, backlog=-514,
> > bindAddr=0xfffffdfe <Address 0xfffffdfe out of bounds>)
> >     at engine.c:647
> > #7  0x0804f05c in thread_wrapper (arg=0x0) at http.c:160
> > #8  0xb7fd83cd in start_thread () from /lib/libpthread.so.0
> > #9  0xb7de31da in clone () from /lib/libc.so.6
> >
> > Thread 1 (Thread -1210952016 (LWP 11589)):
> > #0  0xffffe410 in ?? ()
> > #1  0xbffff050 in ?? ()
> > #2  0x00000002 in ?? ()
> > #3  0x00000000 in ?? ()
> > #4  0xb7def13e in __lll_mutex_lock_wait () from /lib/libc.so.6
> > #5  0xb7d8fa1b in _L_mutex_lock_2967 () from /lib/libc.so.6
> > #6  0x00005a54 in ?? ()
> > #7  0x00000000 in ?? ()
> > #8  0xb7e40ff4 in ?? () from /lib/libc.so.6
> > #9  0x00000000 in ?? ()
> > #10 0x00000000 in ?? ()
> > #11 0xbffff0b8 in ?? ()
> > #12 0xb7da4590 in tzset_internal () from /lib/libc.so.6
> > #13 0xb7da4590 in tzset_internal () from /lib/libc.so.6
> > #14 0xb7da504e in tzset () from /lib/libc.so.6
> > #15 0xb7da9c94 in strftime_l () from /lib/libc.so.6
> > #16 0xb7da9b6f in strftime () from /lib/libc.so.6
> > #17 0x0804f16b in log_log (s=0x0) at log.c:226
> > #18 <signal handler called>
> > #19 0xb7d8c52c in _int_malloc () from /lib/libc.so.6
> > #20 0xb7d8dd59 in calloc () from /lib/libc.so.6
> > #21 0x0805de78 in xcalloc (count=-1209784240, nbytes=-1209784240) at
> > xmalloc.c:93
> > #22 0x08064f80 in connectchild (parent=0xb7e40ff4, child=0x80b5a60) at
> > process_common.c:163
> > #23 0x080526dc in initprocesstree (pt_r=0x80b5a60, size_r=0x808c350,
> > oldpt_r=0x2298, oldsize_r=0x808c348) at process.c:354
> > #24 0x0805b49d in validate () at validate.c:140
> > #25 0x08050eb3 in main (argc=0, argv=0xbffff8f4) at monitor.c:470
> > #0  0xffffe410 in ?? ()
> >
> > any ideas?
> >
> > On 10/20/05, Jan-Henrik Haukeland <address@hidden> wrote:
> >
> >>On 20. okt. 2005, at 16.26, Eli Yukelzon wrote:
> >>
> >>
> >>>Ok. I'll keep an eye on my servers, and see when it happens.
> >>
> >>Great, but as you can see from the output you sent, there are no
> >>debug info in the backtrace.  Make sure that you run the monit binary
> >>with debug info as explained in a previous mail. Do a test run and
> >>make sure that the backtrace looks similar to the one I sent. I.e.
> >>you must have stuff like this in the trace so we can find the
> >>function creating problems.
> >>
> >>#2  0x08050d69 in can_read (socket=5, timeout=-514) at net.c:475
> >>
> >>instead of ?? like you have here,
> >>
> >>#3  0xb7d152f0 in ?? ()
> >>
> >>
> >>Regards
> >>
> >>--
> >>Jan-Henrik Haukeland
> >>Mobil +47 97141255
> >>
> >>
> >>
> >>--
> >>To unsubscribe:
> >>http://lists.nongnu.org/mailman/listinfo/monit-general
> >>
> >
> >
> >
> > --
> > 2B OR NOT 2B = FF
> >
> >
> > --
> > To unsubscribe:
> > http://lists.nongnu.org/mailman/listinfo/monit-general
>
>
>
> --
> To unsubscribe:
> http://lists.nongnu.org/mailman/listinfo/monit-general
>


--
2B OR NOT 2B = FF