Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM, PEM
Known Affected Versions:
11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.4.1, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
12.0.0, 11.6.0 HF6, 11.5.3 HF2, 11.4.1 HF9
Opened: Nov 19, 2014 Severity: 2-Critical Related Article:
K16709
If inside a proc or control statement (if, for, while) and a parking command (like table, session, open, send, RESOLVE::lookup) which is called from catch statement followed by a command which results in TCL error (caught), TMM will core with SIGFPE panic and this message: panic: TclExecuteByteCode execution failure: end stack top < start stack top Example (THIS CODE MAY CAUSE TMM TO CRASH if this procedure is called): proc id491771 { # WILL CAUSE TMM TO CRASH catch { [table lookup "key"] } } The correct usage of "catch" is without the brackets: proc id491771 { catch { table lookup "key" } }
TMM cores with a SIGFPE and this panic string: panic: TclExecuteByteCode execution failure: end stack top < start stack top
1) A parking command like "table" 2) The very next operation generates an error 3) Both commands are inside a "catch" block 4) And this catch block exists within a proc or control statement (e.g., if, for, while)
Any command which completes without parking after the parking command but before the error will prevent the issue. For instance set A "a" Another solution is to move "catch" statement outside of proc or control statement into body of script. Alternately remove the square brackets that indicate that the result of the command should be evaluated in this specific case. The use of brackets in this way is likely a mistake in coding of the iRule.
None