#4056 [continue] result incompat with Tcl 8.4 ?

obsolete: 8.5.0
open
7
2011-04-12
2008-06-30
Anonymous
No

Version tcl8.5-thread-linux-x86_64 downloaded 2008-06-12.
OS Fedora 9
Old program suddenly fails on this system. Here is a snippet that when run via wish8.5 fails with an error in the eval command. But when the next line puts is uncommented it performs the eval with no error.
###########################################3
set fong "--EVAL set wrap 490"
while { 1 } {
catch {
if { [regexp {^--EVAL(.*)} $fong waste fong ] } {
puts "fong was an EVAL"
eval $fong
##### Uncomment the next command and the eval works
##### correctly
#puts -nonewline ""
continue}
puts "Went on past"
continue
} error
if { $error != "" } {
puts "There was an error, the catch value is $error"
exit
}
puts "exiting with wrap set to $wrap"
exit
}

Discussion

  • Alexandre Ferrieux

    • priority: 5 --> 7
    • assigned_to: pvgoran --> msofer
     
  • Alexandre Ferrieux

    Logged In: YES
    user_id=496139
    Originator: NO

    Hmmm, half a red herring there.
    First, notice that checking the value of the 2nd arg to [catch] without checking its return value is bad practice (possible collisions).
    Second, the whole report can be simplified to the following:

    set ev {set x 12}
    catch {eval $ev;continue} y
    puts $y ==> 12
    catch {eval {set x 13};continue} y
    puts $y ==>

    Have to check about the contract of [continue] (is it supposed to reset the interp's result ?)
    But indeed the impact of a dynamic eval is strange. Possibly an effect of compilation ?
    Since this is rather linked to basic execution than regexp, reassigning to Miguel.

     
  • Don Porter

    Don Porter - 2008-07-01

    Logged In: YES
    user_id=80530
    Originator: NO

    Can the original reporter please
    confirm this is the first time
    an interp of version Tcl 8.5 has
    been tried, and this is a Tcl 8.4
    to Tcl 8.5 change that is being
    reported?

    If the results are truly from an
    executable downloaded on June 12,
    2008, then they are not a result
    from Tcl 8.5.3 which did not
    exist until Jume 30.

     
  • Don Porter

    Don Porter - 2008-07-01
    • summary: eval after regexp fails unless followed by a puts --> [continue] result incompat with Tcl 8.4 ?
    • milestone: 829411 --> 807996
     
  • Alexandre Ferrieux

    Logged In: YES
    user_id=496139
    Originator: NO

    Don, I do confirm this bug appeared on 8.5.0.
    It is platform-agnostic, you can try it for yourself ;-)

     
  • Alexandre Ferrieux

    • milestone: 807996 --> obsolete: 8.5.0
     
  • Alexandre Ferrieux

    • labels: 104249 --> 105682
     
  • Alexandre Ferrieux

    Logged In: YES
    user_id=496139
    Originator: NO

    OK, this can be traced to 1.101.2.35 on 29 Aug 2006 by Don:
    The Tcl_ResetResult in [break] and [continue] gets commented out.
    But CVS history is not easy to follow with branches.
    Don or Miguel, can you explain this /* ... */ ?

    6500 : msofer 1.73 case INST_CONTINUE:
    6501 : dgp 1.101.2.35 /*
    6502 : dgp 1.101.2.5 DECACHE_STACK_INFO();
    6503 : msofer 1.73 Tcl_ResetResult(interp);
    6504 : dgp 1.101.2.5 CACHE_STACK_INFO();
    6505 : dgp 1.101.2.35 */

     
  • miguel sofer

    miguel sofer - 2008-07-01
    • assigned_to: msofer --> dgp
     
  • miguel sofer

    miguel sofer - 2008-07-01

    Logged In: YES
    user_id=148712
    Originator: NO

    That seems to have been introduced in revision 1.239, with the ChangeLog entry
    2006-07-21 Miguel Sofer <msofer@users.sf.net>
    * generic/tclExecute.c:
    * tests/execute.test (execute-9.1): dgp's fix for [Bug 1522803].
    First appeared in 8.5a6 not 8.5.0.

     
  • Alexandre Ferrieux

    Logged In: YES
    user_id=496139
    Originator: NO

    Looking at your comment at the time on 1522803:

    Worth recording dgp's explanation in the chat: "the entire
    patch is general reform. Do the reset operation in the one
    right place, not here, there, and everywhere."

    I then tried to identify that "one right place" and I think it is:

    case INST_END_CATCH:
    catchTop--;
    Tcl_ResetResult(interp);

    Now I have not yet pinpointed the reason why it seems to skip the INST_END_CATCH in that case.

     
  • Alexandre Ferrieux

    Logged In: YES
    user_id=496139
    Originator: NO

    OK got it now.
    The problem is that INST_END_CATCH is executed too late:
    In [catch {...} somevar], "somevar" is set *before* INST_END_CATCH.

    In my example: [catch {eval $ev;continue} y], I have verified this fact by single-stepping through TEBC.
    Full disassembly below. The interesting part is the sequence:

    (43) pushResult
    (44) storeScalar1 %v1 # var "y"
    (46) pop
    (47) pushReturnCode
    (48) endCatch

    As you can see, the ResetResult in endCatch comes after the pushResult/storeScalar !
    Notice that the example includes an [eval] in order to touch the interp's result.
    Indeed, [catch {set x 12;continue} y] skips the bug by simply not touching the result in the first place.
    While [catch {eval {set x 12};continue} y] correctly shows the misbehavior.

    I'd say the "one right place" is rather after the line

    if ((result == TCL_CONTINUE) || (result == TCL_BREAK)) {

    (a few lines below the processExceptionReturn: label).
    Do you agree ?

    FULL DISASS:

    Command 2: "catch {eval $ev;continue} y"
    (5) startCommand +44 1 # next cmd at pc 49
    (14) beginCatch4 0
    Command 3: "eval $ev"
    (19) push1 1 # "eval"
    (21) loadScalar1 %v0 # var "ev"
    (23) invokeStk1 2
    (25) pop
    Command 4: "continue"
    (26) startCommand +10 1 # next cmd at pc 36
    (35) continue
    (36) storeScalar1 %v1 # var "y"
    (38) pop
    (39) push1 2 # "0"
    (41) jump1 +7 # pc 48
    (43) pushResult
    (44) storeScalar1 %v1 # var "y"
    (46) pop
    (47) pushReturnCode
    (48) endCatch
    (49) pop

     
  • Don Porter

    Don Porter - 2008-07-01
    • assigned_to: dgp --> msofer
    • labels: 105682 --> 47. Bytecode Compiler
     
  • Don Porter

    Don Porter - 2008-07-01

    Logged In: YES
    user_id=80530
    Originator: NO

    passing to miguel. The issue
    seems to be making sure the
    bytecode execution engine
    faithfully emulates Tcl's
    practice of resetting the interp
    result before each Tcl_CmdProc
    is called.

     
  • Don Porter

    Don Porter - 2009-04-02

    see also 2433843

     
  • miguel sofer

    miguel sofer - 2011-04-12
    • assigned_to: msofer --> dgp
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks