Segmentation Fault (core dumped) with xymond_alert
I bumped into this again today. I was working up some new alert conditions and tested them with:
xymondmd xymond_alert --config=foo.cfg --test foo.bar.com msgs --color=red
It works as expected if foo.bar.com is defined, but if that host _isn't_ defined in the hosts.cfg, xymond_alert core dumps.
For 4/3/17 on Solaris, the stack of the dump looks like:
fee12d10 strlen (37c93, ffbf50b4, 96164, 0, 0, 0) + 50 fee81924 vfprintf (50190, 37c68, ffbf50a8, 0, a0ba4, fee81424) + ec 0001a554 traceprintf (37c68, af7e8, 96160, 0, 50190, 4b800) + 84 0001c2fc criteriamatch (7, 55030, 0, 0, 0, 4bc00) + e4 0001e8b4 next_recipient (aff30, ffbf51a8, 0, 0, 4bc24, 4bc28) + 90 00017054 send_alert (aff30, 501b0, 0, ffbf51a8, 4bc00, ffff7fe4) + 17c 00034550 main (0, 0, 0, 0, 501b0, aff30) + 1368 00014940 _start (0, 0, 0, 0, 0, 0) + 5c
Granted that in production xymond_alert will probably not be fed an undefined host, but it would be nicer if it handled the condition a little more elegantly.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
On Thu, May 7, 2015 9:56 am, John Thurston wrote:
I bumped into this again today. I was working up some new alert conditions and tested them with:
xymondmd xymond_alert --config=foo.cfg --test foo.bar.com msgs --color=red
It works as expected if foo.bar.com is defined, but if that host _isn't_ defined in the hosts.cfg, xymond_alert core dumps.
For 4/3/17 on Solaris, the stack of the dump looks like:
fee12d10 strlen (37c93, ffbf50b4, 96164, 0, 0, 0) + 50 fee81924 vfprintf (50190, 37c68, ffbf50a8, 0, a0ba4, fee81424) + ec 0001a554 traceprintf (37c68, af7e8, 96160, 0, 50190, 4b800) + 84 0001c2fc criteriamatch (7, 55030, 0, 0, 0, 4bc00) + e4 0001e8b4 next_recipient (aff30, ffbf51a8, 0, 0, 4bc24, 4bc28) + 90 00017054 send_alert (aff30, 501b0, 0, ffbf51a8, 4bc00, ffff7fe4) + 17c 00034550 main (0, 0, 0, 0, 501b0, aff30) + 1368 00014940 _start (0, 0, 0, 0, 0, 0) + 5c
Granted that in production xymond_alert will probably not be fed an undefined host, but it would be nicer if it handled the condition a little more elegantly.
This looks like another saved-by-glibc-NULL handling thing, unfortunately, which is why it doesn't show up on the Linux side.
Can you try the attached patch?
-jc
On 5/7/2015 10:10 AM, J.C. Cleaver wrote:
- snip -
- snip -
This looks like another saved-by-glibc-NULL handling thing, unfortunately, which is why it doesn't show up on the Linux side.
Can you try the attached patch?
xymoncmd xymond_alert --config=foo.cfg --test foo.bar.com msgs --color=red
It works as expected if foo.bar.com is defined, but if that host _isn't_ defined in the hosts.cfg, xymond_alert core dumps.
On Thu, May 7, 2015 9:56 am, John Thurston wrote:
It behaves much better now. Thank you! Can I assume this will make it into the next release?
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
On Thu, May 7, 2015 11:45 am, John Thurston wrote:
On 5/7/2015 10:10 AM, J.C. Cleaver wrote:
- snip -
- snip -
This looks like another saved-by-glibc-NULL handling thing, unfortunately, which is why it doesn't show up on the Linux side.
Can you try the attached patch?
xymoncmd xymond_alert --config=foo.cfg --test foo.bar.com msgs --color=red
It works as expected if foo.bar.com is defined, but if that host _isn't_ defined in the hosts.cfg, xymond_alert core dumps.
On Thu, May 7, 2015 9:56 am, John Thurston wrote:
It behaves much better now. Thank you! Can I assume this will make it into the next release?
Yes, just committed.
Regards,
-jc
participants (2)
-
cleaver＠terabithia.org
-
john.thurston＠alaska.gov