Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#3937 puts causes bytecode crash after dict operation

obsolete: 8.5.1
closed-fixed
9
2008-03-16
2008-02-27
eric melbardis
No

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

Discussion

  • eric melbardis
    eric melbardis
    2008-02-27

    • priority: 5 --> 9
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2008-02-27

    • assigned_to: msofer --> dkf
     
  • 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).

     
    • status: open --> pending-works-for-me
     
  • 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.

     
  • eric melbardis
    eric melbardis
    2008-03-07

    • status: pending-works-for-me --> open-works-for-me
     
  • eric melbardis
    eric melbardis
    2008-03-07

    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)

     
  • 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)

     
  • eric melbardis
    eric melbardis
    2008-03-07

    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

     
  • Don Porter
    Don Porter
    2008-03-11

    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?

     
  • eric melbardis
    eric melbardis
    2008-03-11

    Logged In: YES
    user_id=788816
    Originator: YES

    works great, tried both debug & non-debug builds

    thanks

     
  • 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.)

     
  • Logged In: YES
    user_id=79902
    Originator: NO

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

     
  • 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

     
    • assigned_to: dkf --> msofer
     
  • 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.

     
  • 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.

     
  • 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.)

     
    • assigned_to: msofer --> dkf
    • status: open-works-for-me --> closed-fixed