[Tcl-bugs] [ tcl-Bugs-2007198 ] [continue] result incompat with Tcl 8.4 ?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #2007198, was opened at 2008-06-30 20:03
Message generated for change (Settings changed) made by msofer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2007198&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: 47. Bytecode Compiler
Group: obsolete: 8.5.0
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Don Porter (dgp)
Summary: [continue] result incompat with Tcl 8.4 ?

Initial Comment:
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
 }

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

Comment By: Don Porter (dgp)
Date: 2009-04-02 16:51

Message:

see also 2433843

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

Comment By: Don Porter (dgp)
Date: 2008-07-01 12:23

Message:
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.

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

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-07-01 09:57

Message:
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 

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

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-07-01 09:19

Message:
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.

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

Comment By: miguel sofer (msofer)
Date: 2008-07-01 08:41

Message:
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  <ms...@us...>
	* generic/tclExecute.c:
	* tests/execute.test (execute-9.1): dgp's fix for [Bug 1522803].
First appeared in 8.5a6 not 8.5.0.

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

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-07-01 06:36

Message:
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 	*/

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

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-07-01 06:08

Message:
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 ;-)

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

Comment By: Don Porter (dgp)
Date: 2008-07-01 00:13

Message:
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.

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

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-06-30 20:30

Message:
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.

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

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

[Tcl-bugs] [ tcl-Bugs-2007198 ] [continue] result incompat with Tcl 8.4 ?

The Tool Command Language implementation

[Tcl-bugs] [ tcl-Bugs-2007198 ] [continue] result incompat with Tcl 8.4 ?