Is there any suspicion what is the reason for hobbitfetch crash?

This is how often hobbitfetch crashes on my server (I have 16 hosts with pulldata tag):

Tue Feb 10 16:46:22 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 16:11:11 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 16:11:11 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 16:00:35 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 15:20:08 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 14:15:57 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:51:04 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:45:50 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:34:59 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:24:58 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:24:58 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:23:47 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:13:45 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:08:59 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 11:03:22 2009 xymon-server hobbitfetch unknown From -> To red

just another backtrace:

Core was generated by `/home/hob/xymon/server/bin/hobbitfetch --server=xxx.xxx.xxx.xxx --no-daemon --pid'. Program terminated with signal 6, Aborted. #0 0x0095b402 in __kernel_vsyscall () (gdb) backtrace #0 0x0095b402 in __kernel_vsyscall () #1 0x00501d10 in raise () from /lib/libc.so.6 #2 0x00503621 in abort () from /lib/libc.so.6 #3 0x08050ff3 in sigsegv_handler (signum=11) at sig.c:57 #4 <signal handler called> #5 main (argc=4, argv=Cannot access memory at address 0x4 ) at hobbitfetch.c:709 (gdb)

On Thu, Jan 29, 2009 at 9:32 AM, Olivier Beau <obeau79 at gmail.com> wrote:

here's the backtrace

gdb /data/hobbit/server/bin/hobbitfetch core

GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/tls/i686/cmov/libc.so.6...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Core was generated by `/data/hobbit/server/bin/hobbitfetch --server=127.0.0.1 --no-daemon --pidfile=/d'. Program terminated with signal 6, Aborted. #0 0x0804ae65 in main (argc=6, argv=Cannot access memory at address 0x4 ) at hobbitfetch.c:748 748 switch (connwalk->action) { (gdb) bt #0 0x0804ae65 in main (argc=6, argv=Cannot access memory at address 0x4 ) at hobbitfetch.c:748 (gdb)

On 28/01/2009 22:20, Henrik Størner wrote:

...

In <49805E29.6050204 at gmail.com> Olivier Beau <obeau79 at gmail.com> writes:

...

In top, i see that hobbitfetch in at 100% cpu (i'm only doing pulldata on less that 10 hosts)

...

Is there a special signal i should send to hobbitfetch ? or should i just do a kill -9 on it ?..

"kill -6" causes it to dump core, which might be interesting. It's a different bug from the crash, though (and it's been reported before, but I cannot seem to get a handle on what triggers it).

Regards, Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk