Tcl Source Code

Joe Mistachkin reports a crash in [Bug 2017627]: apparently an infinite recursion blowing the stack with CVS HEAD using threaded debug build on Windows XP SP3. 

The stack trace is at http://paste.tclers.tk/1067 and attached here. The first few lines are



CVS HEAD using threaded debug build on Windows XP SP3.

Here is the full stack trace:

tcl86tg.dll!_chkstk() Line 99 Asm
tcl86tg.dll!NRPostProcess(Tcl_Interp * interp=0x009ebe88, int
result=0x00000000, int objc=0x00000000, Tcl_Obj * const * objv=0x00000000)
Line 7419 + 0x10 bytes C
tcl86tg.dll!TclEvalObjEx(Tcl_Interp * interp=0x009ebe88, Tcl_Obj *
objPtr=0x00a5fb30, int flags=0x00000000, const CmdFrame *
invoker=0x0131da9c, int word=0x00000001) Line 5327 + 0x11 bytes C
tcl86tg.dll!Tcl_CatchObjCmd(void * dummy=0x00000000, Tcl_Interp *
interp=0x009ebe88, int objc=0x00000003, Tcl_Obj * const * objv=0x0131dac4)
Line 253 + 0x1e bytes C
tcl86tg.dll!Tcl_EvalObjv(Tcl_Interp * interp=0x009ebe88, int
objc=0x00000003, Tcl_Obj * const * objv=0x0131dac4, int flags=0x00200000)
Line 4079 + 0x15 bytes C

allow_comments - 1

seems like we got them all?? Leaving open for later throrough review

info-23.3 has been fixed now.

Logged In: YES 
user_id=148712
Originator: YES

[eval] now nre-enable, it compiles its scripts. Fixed the interp.test problems, info-23.3 still broken. aku?

Logged In: YES 
user_id=80530
Originator: NO

IINM, issue a) is noted
as Tcl Bug 1669392.

Logged In: YES 
user_id=79902
Originator: NO

Type (a) is not serious, except that we need to check for coverage of all the [info frame] cases after changing it. (When doing this, use "-match glob" so that you don't bind in the exact filename or line number into the match space.)

Type (b) is more interesting; we need to ask ourselves just what are we testing and what is [interp recursionlimit] about preventing. Not that I have an answer to that. :-) Perhaps this question should be asked more widely.

Logged In: YES 
user_id=148712
Originator: YES

REQUEST FOR OPINION (mainly dkf and aku)

As a first step towards NRE-enabling [eval], I tried bytecompiling eval'ed scripts (just subst 0 for TCL_EVAL_DIRECT in tclCmdAH.c). This raises 5 errors in the testsuite, need feedback as to how serious they are. I tend to think somewhere "not serious at all" and "fixable":

(a) [info frame] reports the wrong(?) thing
==== info-23.3 eval'd info frame, literal FAILED
==== Contents of test case:

    eval {
info frame 0
    }

---- Result was:
type source line 793 file /home/CVS/fossil/tmp/tests/info.test cmd {info frame 0} proc ::tcltest::RunTest
---- Result should have been (exact matching):
type eval line 2 cmd {info frame 0} proc ::tcltest::RunTest
==== info-23.3 FAILED

(b) 4 of the [interp recursionlimit] tests fail: interp-29.3.(7,8,10,11). It is the same problem in each:
==== interp-29.3.7 recursion limit error reporting FAILED
==== Contents of test case:

    interp create slave
    after 0 {interp recursionlimit slave 5}
    set r1 [slave eval {
        catch { # nesting level 1
    eval {# 2
        eval {# 3
    eval {# 4
        eval {# 5
     update
     set x ok
}
    }
}
    }
} msg
    }]
    set r2 [slave eval { set msg }]
    interp delete slave
    list $r1 $r2

---- Result was:
0 ok
---- Result should have been (exact matching):
1 {too many nested evaluations (infinite loop?)}
==== interp-29.3.7 FAILED

The error is caused by the fact that TEBC does not check the limits at each command, only every so many instructions (currently 64). If the tests would have updated the limit before the last nested eval, or called a non-bbc'ed command instead of 'set x ok', or attempted to do anything meaningful in that eval'ed script, the limit would have triggered.

Logged In: YES 
user_id=148712
Originator: YES

[foreach] has been committed by dkf on 2008-08-24

Logged In: YES 
user_id=79902
Originator: NO

Done [dict for].

Logged In: YES 
user_id=148712
Originator: YES

[catch], [for], [if] and [while] are NR-enabled in HEAD. Still missing [foreach] and [dict for]

Logged In: YES 
user_id=148712
Originator: YES

The original crash should not happen in HEAD now that [catch] is NR-enabled. Leaving open as reminder for the other commands.

Logged In: YES 
user_id=148712
Originator: YES

Need to NRE-enable Tcl_CatchObjCmd (and others that eval a script: foreach, if, ...).

This also points to NRE-enabling NRPostProcess(), or a better approach to TclEvalObjEx?

Logged In: YES 
user_id=148712
Originator: YES

Forgot to add: the crashing test is error-1.8:

    proc p {} {
        uplevel 1 catch p error
    }
    p

File Added - 284581: 1067.html.gz