Bug ID 491771: Parking command called from inside catch statement

Last Modified: Apr 10, 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:


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.

Fix Information


Behavior Change