Bug ID 491771: Parking command called from inside catch statement

Last Modified: Feb 13, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP LTM, PEM(all modules)

Known Affected Versions:
11.4.1, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 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.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5

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 AskF5 Article:
K16709

Symptoms

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" } }

Impact

TMM cores with a SIGFPE and this panic string: panic: TclExecuteByteCode execution failure: end stack top < start stack top

Conditions

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)

Workaround

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.

Fix Information

None

Behavior Change