[Tcl-bugs] [ tcl-Bugs-1903325 ] puts causes bytecode crash after dict operation

[SourceForge.net <no...@so...>]

Bugs item #1903325, was opened at 2008-02-27 18:52
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1903325&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 46. Bytecode Compiler
Group: current: 8.5.1
>Status: Closed
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: eric melbardis (melbardis)
>Assigned to: Donal K. Fellows (dkf)
Summary: puts causes bytecode crash after dict operation

Initial Comment:
get following panic doing a puts after a dictionary operation.

windows xp latest/ tcl8.5.1

------------------------------------------------------
Bad stack top 4 at pc 82 in TclExecuteByteCode (min 0, max 3)
 executing puts "key=$key $args"
TclExecuteByteCode execution failure: bad stack top


-------------------------------------------------------------------
note: the puts causes the crash

proc xx {idict key args} {
    dict for {id subdict} $idict {
    }
    puts "key=$key $args"
}


set d [dict create]
dict set d 0 {a 1 b test        c abc}

xx $d b -dictionary 



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

>Comment By: Donal K. Fellows (dkf)
Date: 2008-03-16 17:02

Message:
Logged In: YES 
user_id=79902
Originator: NO

Fixed it; managed to figure out where to put instrumentation that let me
track down the problem and fix it. (Problem was [dict for]'s internal jump
pattern being more complex than that understood by the automated stack
depth calculator, requiring the application of a little more magic.)

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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-16 16:00

Message:
Logged In: YES 
user_id=79902
Originator: NO

Note on [puts] innocence: substituting with another interpreted command
leads to same result, but changing method of computing the argument (e.g.
to literal) gets rid of problem.

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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-16 15:58

Message:
Logged In: YES 
user_id=79902
Originator: NO

OK, problem seems to be the code to calculate the maximum stack depth.
This is out of my league; passing to TEBC guru.

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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-16 15:54

Message:
Logged In: YES 
user_id=79902
Originator: NO

Further investigation gives this trace...

% set tcl_traceExec 3; xx $d b -dictionary
1: (15) invoking "xx" "0 {a 1 b test c" "b" "-dictionary"
Calling proc "xx" "0 {a 1 b test c" "b" "-dictionary"

Executing ByteCode 0x00A22E88, refCt 2, epoch 3, interp 0x003DA5C0 (epoch
3)
  Source: "\ndict for {id subdict} $idict {\n}\nputs \"key=$key
$args\"\n"
  Cmds 2, src 56, inst 89, litObjs 5, aux 0, stkDepth 3, code/src 5.14
  Code 288 = header 104+inst 89+litObj 20+exc 56+aux 0+cmdMap 8
  Proc 0x00A40040, refCt 2, args 3, compiled locals 6
  Starting stack top=0
 2:  0 (0) loadScalar1 %v0      # var "idict"
 2:  0 (0) loadScalar1 0 => 0 {a 1 b test c abc}
 2:  1 (2) dictFirst %v5        # temp var 5
 2:  1 (2) dictFirst 5 => "a 1 b test c abc" "0" 0 2:  3 (7) jumpTrue4
+57
# pc 64
 2:  3 (7) jumpTrue4 5 => 0 false
 2:  2 (12) beginCatch4 0
 2:  2 (12) beginCatch4 0 => catchTop=0, stackTop=2
 2:  2 (17) storeScalar4 %v3    # var "id"
 2:  2 (17) storeScalar4 3 <- "0" => 0
 2:  2 (22) pop
 2:  2 (22) pop => discarding "0"
 2:  1 (23) storeScalar4 %v4    # var "subdict"
 2:  1 (23) storeScalar4 4 <- "a 1 b test c abc" => a 1 b test c abc
 2:  1 (28) pop
 2:  1 (28) pop => discarding "a 1 b test c abc"
 2:  0 (29) push1 0     # ""
 2:  1 (29) push1 0 => ""
 2:  1 (31) pop
 2:  1 (31) pop => discarding ""
 2:  0 (32) dictNext %v5        # temp var 5
 2:  0 (32) dictNext 5 => "" "" 1 2:  3 (37) jumpFalse4 -20     # pc 17
 2:  3 (37) jumpFalse4 -20 => 1 true
 2:  2 (42) pop
 2:  2 (42) pop => discarding ""
 2:  1 (43) pop
 2:  1 (43) pop => discarding ""
 2:  0 (44) dictDone %v5        # temp var 5
 2:  0 (44) dictDone 5 =>  2:  0 (49) endCatch
 2:  0 (49) endCatch => catchTop=-1
 2:  0 (50) jump4 +21   # pc 71
 2:  0 (50) jump4 21 => new pc 71
 2:  0 (71) push1 1     # ""
 2:  1 (71) push1 1 => ""
 2:  1 (73) pop
 2:  1 (73) pop => discarding ""
 2:  0 (74) push1 2     # "puts"
 2:  1 (74) push1 2 => "puts"
 2:  1 (76) push1 3     # "key="
 2:  2 (76) push1 3 => "key="
 2:  2 (78) loadScalar1 %v1     # var "key"
 2:  2 (78) loadScalar1 1 => b
 2:  3 (80) push1 4     # " "
 2:  4 (80) push1 4 => " "

Bad stack top 4 at pc 82 in TclExecuteByteCode (min 0, max 3)
 executing puts "key=$key $args"
TclExecuteByteCode execution failure: bad stack top

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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-16 15:51

Message:
Logged In: YES 
user_id=79902
Originator: NO

Confirmed innocence of [puts], and confirmed requirement for
--enable-symbols=all.

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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-12 09:27

Message:
Logged In: YES 
user_id=79902
Originator: NO

I suspect that this bug is only exhibited with --enable-symbols=all (or
whatever debugging option enables the extensive stack checks) if at all.
I'm pretty sure that [puts] is wholly innocent.

(I've not had time to dig into this in any detail, alas.)

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

Comment By: eric melbardis (melbardis)
Date: 2008-03-11 19:23

Message:
Logged In: YES 
user_id=788816
Originator: YES

works great, tried both debug & non-debug builds

thanks


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

Comment By: Don Porter (dgp)
Date: 2008-03-11 19:09

Message:
Logged In: YES 
user_id=80530
Originator: NO


Release candidate for Tcl 8.5.2 is at

ftp://ftp.tcl.tk/pub/tcl/tcl8_5/

Can you check whether it still has
this bug?


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

Comment By: eric melbardis (melbardis)
Date: 2008-03-07 15:19

Message:
Logged In: YES 
user_id=788816
Originator: YES

here it is: right before  the scripts invokes xx ...

ByteCode 0x008D4048, refCt 1, epoch 3, interp 0x008987C8 (epoch 3)
  Source "\n    dict for {id subdict} $idict {\n    }\n    puts \"key"
  Cmds 2, src 68, inst 89, litObjs 5, aux 0, stkDepth 3, code/src 4.24
  Code 288 = header 104+inst 89+litObj 20+exc 56+aux 0+cmdMap 8
  Proc 0x008D8BE0, refCt 1, args 3, compiled locals 6
      slot 0, scalar, arg, "idict"
      slot 1, scalar, arg, "key"
      slot 2, scalar, arg, "args"
      slot 3, scalar, "id"
      slot 4, scalar, "subdict"
      slot 5, scalar, temp
  Exception ranges 2, depth 2:
      0: level 0, catch, pc 17-31, catch 55
      1: level 1, loop, pc 29-31, continue 32, break 44
  Commands 2:
      1: pc 0-73, src 5-40   	   2: pc 74-87, src 46-66
  Command 1: "dict for {id subdict} $idict {\n    }"
    (0) loadScalar1 %v0 	# var "idict"
    (2) dictFirst %v5 	# temp var 5
    (7) jumpTrue4 +57 	# pc 64
    (12) beginCatch4 0 
    (17) storeScalar4 %v3 	# var "id"
    (22) pop 
    (23) storeScalar4 %v4 	# var "subdict"
    (28) pop 
    (29) push1 0 	# ""
    (31) pop 
    (32) dictNext %v5 	# temp var 5
    (37) jumpFalse4 -20 	# pc 17
    (42) pop 
    (43) pop 
    (44) dictDone %v5 	# temp var 5
    (49) endCatch 
    (50) jump4 +21 	# pc 71
    (55) pushReturnOpts 
    (56) pushResult 
    (57) dictDone %v5 	# temp var 5
    (62) endCatch 
    (63) returnStk 
    (64) pop 
    (65) pop 
    (66) dictDone %v5 	# temp var 5
    (71) push1 1 	# ""
    (73) pop 
  Command 2: "puts \"key=$key $args\""
    (74) push1 2 	# "puts"
    (76) push1 3 	# "key="
    (78) loadScalar1 %v1 	# var "key"
    (80) push1 4 	# " "
    (82) loadScalar1 %v2 	# var "args"
    (84) concat1 4 
    (86) invokeStk1 2 
    (88) done 



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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-07 15:16

Message:
Logged In: YES 
user_id=79902
Originator: NO

Can you print out the result of:
  tcl::unsupported::disassemble proc xx
(executed sometime after xx is defined but before the crash happens)

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

Comment By: eric melbardis (melbardis)
Date: 2008-03-07 15:08

Message:
Logged In: YES 
user_id=788816
Originator: YES

hi

i donwloaded latest virgin copy of 8.5.1 of the net.

first test was a production build: ./configure CC=cl
   - worked, no issue

next test was a debug build: ./configure CC=cl --enable-symbols=all
--enable-threads --enable-load

   -  the error occured

(i also tried with just --enable-symbols=all - same error)

my system is XP sp2, latest updates about a week ago

using MSVC 13.1 (.net 2003)






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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-06 23:11

Message:
Logged In: YES 
user_id=79902
Originator: NO

Pat Thoyts reports that he can't reproduce with 8.5.1. I can't reproduce
with HEAD on Linux with a symbols build.

Unless/until this can be duplicated "in the lab", I can't chase.

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

Comment By: Donal K. Fellows (dkf)
Date: 2008-03-06 21:40

Message:
Logged In: YES 
user_id=79902
Originator: NO

Can't see it in either 8.5.0 or 8.5.2b1 on WinXP, even when using exactly
the code presented. (8.5.0 is an ActiveTcl build, 8.5.2b1 is my own build
of the HEAD or something very close to it).

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

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