core dump, Xymon 4.3.2, loadalerts.c:308, i686 Linux RedHat 5 🔗 link

[xymon at xymon1 tmp]$ file core.30776

core.30776: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV),
SVR4-style, from 'xymond_alert'

[xymon at xymon1 tmp]$ gdb ../bin/xymond_alert core.30776

GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2)

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>;

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"

and "show warranty" for details.

This GDB was configured as "i386-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>;...

Reading symbols from /home/xymon/server/bin/xymond_alert...done.

Reading symbols from /lib/libpcre.so.0...(no debugging symbols
found)...done.

Loaded symbols for /lib/libpcre.so.0

Reading symbols from /lib/librt.so.1...(no debugging symbols
found)...done.

Loaded symbols for /lib/librt.so.1

Reading symbols from /lib/libc.so.6...(no debugging symbols
found)...done.

Loaded symbols for /lib/libc.so.6

Reading symbols from /lib/libpthread.so.0...(no debugging symbols
found)...done.

Loaded symbols for /lib/libpthread.so.0

Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.

Loaded symbols for /lib/ld-linux.so.2

Core was generated by `xymond_alert
--checkpoint-file=/home/xymon/server/tmp/alert.chk --checkpoint-in'.

Program terminated with signal 6, Aborted.

#0  0x00485402 in __kernel_vsyscall ()

(gdb) bt

#0  0x00485402 in __kernel_vsyscall ()

#1  0x0066bdf0 in raise () from /lib/libc.so.6

#2  0x0066d701 in abort () from /lib/libc.so.6

#3  0x0805ee13 in sigsegv_handler (signum=11) at sig.c:57

#4  <signal handler called>

#5  0x006b2eca in strcmp () from /lib/libc.so.6

#6  0x08053e4f in preprocess (buf=<value optimized out>) at
loadalerts.c:138

#7  0x08054272 in load_alertconfig (configfn=0x0, defcolors=56,
defaultinterval=1800) at loadalerts.c:308

#8  0x0804aafa in main (argc=1918990080, argv=0xbff783a4) at
xymond_alert.c:831

(gdb) quit

[xymon at xymon1 tmp]$ uname -a

Linux xymon1 2.6.18-238.5.1.el5 #1 SMP Mon Feb 21 05:53:18 EST 2011 i686
i686 i386 GNU/Linux

 
[xymon at xymon1 tmp]$ ls -lrt core*

-rw------- 1 xymon xymon 4014080 Apr  6 13:58 core.29948

-rw------- 1 xymon xymon 4014080 Apr  6 13:59 core.30244

-rw------- 1 xymon xymon 4014080 Apr  6 14:00 core.30371

-rw------- 1 xymon xymon 3956736 Apr  6 14:01 core.30418

-rw------- 1 xymon xymon 3956736 Apr  6 14:02 core.30432

-rw------- 1 xymon xymon 3956736 Apr  6 14:03 core.30776

 
Is there an easy way to verify your files in analysis.d when it refers
to line numbers in the logs and you use multiple include files?

 
David Gore (v965-3670) 
Network Management Systems (NMS) 
IMPACT Transport Team Lead - SCSA, SCNA 
Page: 1-800-PAG-eMCI pin 1406090 
Vnet: 965-3676

On Thu, 07 Apr 2011 11:52:24 +0000, "Gore, David W"

<user-3e5761c68b56@xymon.invalid> wrote:

Looks like it is related to some macro in your config file.

"xymoncmd xymoncfg analysis.cfg" will dump the file following all the
include's.


Regards,
Henrik

Henrik,

It could well be.  We had no pages go out last night and I think it is because there is an 8k limit on macros in alerts.cfg.  xymond_alert seg faults when one of the macros exceeds the 8k limit.  Should we just assume an 8k limit and work around that or do you see making that configurable in the future?  I see the limit may be set in load_alerts.c.

~David

-----Original Message-----
From: user-ce4a2c883f75@xymon.invalid [mailto:user-ce4a2c883f75@xymon.invalid] 
Sent: Thursday, April 07, 2011 13:29
To: Gore, David W
Cc: xymon at xymon.com
Subject: Re: [Xymon] core dump, Xymon 4.3.2, loadalerts.c:308, i686 Linux RedHat 5

On Thu, 07 Apr 2011 11:52:24 +0000, "Gore, David W"
<user-3e5761c68b56@xymon.invalid> wrote:

Looks like it is related to some macro in your config file.

"xymoncmd xymoncfg analysis.cfg" will dump the file following all the
include's.


Regards,
Henrik

David wrote:

Hadn't noticed that. Such random limits are a "bad thing(TM)", especially when they are a)undocumented, and b)unnecessary.

This patch should eliminate that limit. I haven't tested it, so use at your own risk - but it seems fairly trivial so I would expect it to work :-))


Regards,
Henrik

Den 07-04-2011 22:29, Henrik Størner skrev:

:-))

Doh - didn't even link with that patch. Try this instead.


Regards,
Henrik