[Tcl-bugs] [ tcl-Bugs-406709 ] Bytecode error -TclExecuteByteCode error

[nobody <no...@so...>]

Bugs #406709, was updated on 2001-03-07 07:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=406709&group_id=10894

Category: Bytecodes
Group: 8.3.2
Status: Open
Priority: 9
Submitted By: Neil Madden
Assigned to: Nobody/Anonymous
Summary: Bytecode error -TclExecuteByteCode error

Initial Comment:
The following script causes a bytecode error on Win98SE. The error causes Wish to hang, and CPU 
and memory usage goes up to near maximum. The wish and console windows remain visible but do 
not redraw if you cover and uncover them with another app (you are left with white 
window-shaped objects). The only solution is to reboot the computer.

Operating System: Windows 98 Second Edition
Tcl Version: 8.3.2
Extensions: none

Error: TclExecuteByeCode execution failure: end stack top != start stack top

Script:

proc createByteCodeBug {} {
    set path [frame .frame];

    entry $path.command;
    text $path.text;

    pack $path.command -side bottom -fill x -expand 1;
    pack $path.text -side top -fill both -expand 1;

    $path.command configure -state disabled;
    $path.text configure -state normal;
    focus $path.text;
    foreach {dir equiv} [list Up k Down j Left h Right l] {
        bind $path.text <Key-$dir> {}
        bind $path.text <Key-$equiv> [concat [bind Text <Key-$dir>]; break];
    }
}

createByteCodeBug




----------------------------------------------------------------------

Comment By: Donal K. Fellows
Date: 2001-03-09 03:17

Message:
Logged In: YES 
user_id=79902

Problem existed in 8.0.4 and still exists in CVS HEAD of
8-Mar-2001.

----------------------------------------------------------------------

Comment By: miguel sofer
Date: 2001-03-08 11:35

Message:
Logged In: YES 
user_id=148712

A minimal script that exercises the bug is:
while 1 {puts [break]}



----------------------------------------------------------------------

Comment By: miguel sofer
Date: 2001-03-08 08:03

Message:
Logged In: YES 
user_id=148712

The problem is with loop exception ranges in general: they
do not register (as catch does) the stack level at begin,
and do not restore the stack on return.

To illustrate, this also bombs:
proc a {} {
    for {set i 0} {$i < 10} {incr i} {
        list [continue]
    }
 }

The problem appears *also* in tcl8.4a2 (and I guess many
other versions).

The bad exit from "panic" seems to be unique to W98; at
least it does not happen on W95.

----------------------------------------------------------------------

Comment By: Donal K. Fellows
Date: 2001-03-08 07:30

Message:
Logged In: YES 
user_id=79902

Bytecodes for my little script that exercises the problem
follow:

ByteCode 0x370c8, refCt 1, epoch 0, interp 0x24e30 (epoch 0)
  Source "foreach a a {puts [concat a;break]}"
  Cmds 4, src 35, inst 35, litObjs 4, aux 1, stkDepth 3,
code/src 6.06
  Code 212 = header 100+inst 35+litObj 16+exc 28+aux
8+cmdMap 16
  Proc 0x302d0, refCt 1, args 0, compiled locals 3
      slot 0, scalar, temp
      slot 1, scalar, temp
      slot 2, scalar, "a"
  Exception ranges 1, depth 1:
      0: level 1, loop, pc 17-28, continue 10, break 32
  Commands 4:
      1: pc 0-33, src 0-34         2: pc 17-28, src 13-33
      3: pc 19-24, src 19-26       4: pc 26-26, src 28-32
  Command 1: "foreach a a {puts [concat a;break]}"
    (0) push1 0         # "a"
    (2) storeScalar1 0  # temp var 0
    (4) pop 
    (5) foreach_start4 0 
    (10) foreach_step4 0 
    (15) jumpFalse1 17          # pc 32
  Command 2: "puts [concat a;break]"
    (17) push1 1        # "puts"
  Command 3: "concat a"
    (19) push1 2        # "concat"
    (21) push1 0        # "a"
    (23) invokeStk1 2 
    (25) pop 
  Command 4: "break"
    (26) break 
    (27) invokeStk1 2 
    (29) pop 
    (30) jump1 -20      # pc 10
    (32) push1 3        # ""
    (34) done 

I believe the problem is that the break doesn't clobber the
values pushed onto the stack that were supposed to be
removed before reaching the catching context (the foreach).

----------------------------------------------------------------------

Comment By: Donal K. Fellows
Date: 2001-03-08 05:40

Message:
Logged In: YES 
user_id=79902

The following scriptlet also exercises the bug:
   proc a {} {foreach a b {puts [concat a; break]}}; a
panic() message was (after line breaking):
   TclExecuteByteCode: done instruction at pc 34:
                   stack top 1 != entry stack top 0
   TclExecuteByteCode execution failure: end stack top !=
start stack top
Stack trace follows:
#0  0xff11a118 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff0b95b0 in abort () from /usr/lib/libc.so.1
#2  0xff31d7f0 in Tcl_PanicVA (
    format=0xff3560a0 "TclExecuteByteCode execution failure:
end stack top != start stack top", argList=0xffbedb18) at
./../generic/tclPanic.c:93
#3  0xff31d838 in Tcl_Panic (
    arg1=0xff3560a0 "TclExecuteByteCode execution failure:
end stack top != start stack top") at
./../generic/tclPanic.c:121
#4  0xff2e4140 in TclExecuteByteCode (interp=0x24898,
codePtr=0x2d4b0)
    at ./../generic/tclExecute.c:642
#5  0xff2b0590 in Tcl_EvalObjEx (interp=0x24898,
objPtr=0x2d2f8, flags=0)
    at ./../generic/tclBasic.c:2837
#6  0xff32c644 in TclObjInterpProc (clientData=0x2f7f8,
interp=0x24898, 
    objc=1, objv=0x262e0) at ./../generic/tclProc.c:1014
#7  0xff2e4c98 in TclExecuteByteCode (interp=0x24898,
codePtr=0x334b8)
    at ./../generic/tclExecute.c:874
#8  0xff2b0590 in Tcl_EvalObjEx (interp=0x24898,
objPtr=0x2cf50, flags=0)
    at ./../generic/tclBasic.c:2837
#9  0xff2f91fc in Tcl_RecordAndEvalObj (interp=0x24898,
cmdPtr=0x2cf50, 
    flags=0) at ./../generic/tclHistory.c:142
#10 0xff314678 in Tcl_Main (argc=1, argv=0xffbee9d4, 
    appInitProc=0x10ae0 <Tcl_AppInit>) at
./../generic/tclMain.c:315
#11 0x10acc in main (argc=1, argv=0xffbee9d4) at
./../unix/tclAppInit.c:99


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=406709&group_id=10894