Parenthesis failure in combo.cfg
list John Thurston
I'm pulling what little hair I have over the behavior of combostatus with parenthesis in combo.cfg
The man file specifically says, "All operators have EQUAL PRECEDENCE. If you need something evaluated in a specific order, use parentheses to group the expressions..." I need to implement an exclusive-or, so certainly need to ensure the order of operations. But I couldn't make it work, so I started simplifying my expression to find where it broke. The failure conditions are pretty depressing :(
This simple expression works as expected
foo.x = bar.a && zab.a
as does
foo.x = bar.a && (zab.a==0)
but it fails with a core dump if I simply reverse the terms
foo.x = (zab.a==0) && bar.a
it also dumps core if I wrap the earlier expression in parens
foo.x = (bar.a && (zab.a==0))
it works with extra parens for a simple term
foo.x = ((bar.a))
but dumps core there if a more complex expression in the parens
foo.x = ((bar.a==0))
I am unable to come up with a way to implement anything useful with these limitations. I do understand that combostatus is kind of a fringe feature, but there are so many business functions it enables that I really want it to work!
I'm running 4.3.21 on Solaris 10. Is combostatus working for anyone else?
--
Do things because you should, not just because you can.
John Thurston XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list John Thurston
▸
On 10/6/2015 4:28 PM, John Thurston wrote:
I'm pulling what little hair I have over the behavior of combostatus with parenthesis in combo.cfg The man file specifically says, "All operators have EQUAL PRECEDENCE. If you need something evaluated in a specific order, use parentheses to group the expressions..." I need to implement an exclusive-or, so certainly need to ensure the order of operations. But I couldn't make it work, so I started simplifying my expression to find where it broke. The failure conditions are pretty depressing :(
- snip -
▸
it works with extra parens for a simple term foo.x = ((bar.a)) but dumps core there if a more complex expression in the parens foo.x = ((bar.a==0))
- snip - Looking at the stack in the resulting core file on my Solaris system, I suspect update_combotests is running off the end of a string:
feeaebc4 _lwp_kill (6, 0, 0, fee8e06c, ffffffff, 6) + 8 fee229b0 abort (0, 1, 32cb4, ffb3c, fef25518, 0) + 110 000175f0 sigsegv_handler (b, 0, ffbf3fb8, 1, 676f767c, 696e666f) + 30 feeaafec __sighndlr (b, 0, ffbf3fb8, 175c0, 0, 1) + c fee9f69c call_user_handler (b, 0, 0, 0, ff062a00, ffbf3fb8) + 3b8 fee9f884 sigacthandler (b, 0, ffbf3fb8, 3d, 0, 0) + 60 --- called from signal handler with signal 11 (SIGSEGV) --- fee12d10 strlen (1f7ac, ffbf51c8, ffbff912, 0, 0, 0) + 50 fee817b8 sprintf (ffbf9a00, 7fffffff, 7ffffc00, ffbff908, 0, 0) + 40 00013fb4 update_combotests (1f778, 1f788, 43ca8, ffbff908, 0, 40118) + a3c 000130e0 _start (0, 0, 0, 0, 0, 0) + 5c
And, I remembered another host running Xymon 4.3.17 on Centos 6.5 That host seems to be happy with nested parens and interesting constructs. It doesn't core dump when fed things like: foo.x = ((bar.a)) foo.y = (( 1 || (bar.a==0) || 1)) This is much more usable. Unfortunately, it will be much more difficult to make this Centos box handle the combo logic for me.
▸
--
Do things because you should, not just because you can.
John Thurston XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Andy Smith
▸
John Thurston wrote:
I'm pulling what little hair I have over the behavior of combostatus with parenthesis in combo.cfg The man file specifically says, "All operators have EQUAL PRECEDENCE. If you need something evaluated in a specific order, use parentheses to group the expressions..." I need to implement an exclusive-or, so certainly need to ensure the order of operations. But I couldn't make it work, so I started simplifying my expression to find where it broke. The failure conditions are pretty depressing :( This simple expression works as expected foo.x = bar.a && zab.a as does foo.x = bar.a && (zab.a==0) but it fails with a core dump if I simply reverse the terms foo.x = (zab.a==0) && bar.a it also dumps core if I wrap the earlier expression in parens foo.x = (bar.a && (zab.a==0)) it works with extra parens for a simple term foo.x = ((bar.a)) but dumps core there if a more complex expression in the parens foo.x = ((bar.a==0)) I am unable to come up with a way to implement anything useful with these limitations. I do understand that combostatus is kind of a fringe feature, but there are so many business functions it enables that I really want it to work! I'm running 4.3.21 on Solaris 10. Is combostatus working for anyone else?
John, The Revision ID of combostatus.c at 4.3.17 was 7092, there have been two changes since then, and I am about to submit a third to solve another problem that I have, but whilst I was researching my change, I didn't see anything particular that would apply to Solaris. Could you test my patch please because I am nervous about extending something already labeled as 'ugly'. -- Andy