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

Close

#1968 aliases do not fire exec traces

obsolete: 8.4b2
closed-fixed
miguel sofer
46. Traces (50)
3
2004-07-13
2002-07-16
Don Porter
No

% proc print args {puts "printtrace $args"}
% proc foo {} {puts orig_foo}
% interp alias {} al_foo {} foo
al_foo
% trace add execution foo enter {print foo}
% trace add execution al_foo enter {print al_foo}
% foo
printtrace foo foo enter
orig_foo
% al_foo
printtrace al_foo al_foo enter
orig_foo
%

The [print foo] trace is missing. It should
have been fired by [al_foo].

The problem seems to be that execution
traces are performed by
TclEvalObjvInternal() and aliases get
evaluated by TclObjInvoke() which
bypasses that and executes the
command procedure directly.

In combination with Bug 582506, it
seems the correct solution may be
to tie execution traces into the
command procedure itself instead
of in TclEvalObjvInternal().

Discussion

  • miguel sofer
    miguel sofer
    2002-07-29

    • priority: 5 --> 3
    • status: open --> open-fixed
     
  • miguel sofer
    miguel sofer
    2002-07-29

    Logged In: YES
    user_id=148712

    Fixed by sending aliases through TEOI. Leaving openas
    reminder to check into the other suggestion. An alternative
    would be to eliminate the independent import mechanism, and
    just use it as a front-end for aliases which are now almost
    as fast.

     
  • Don Porter
    Don Porter
    2002-07-29

    Logged In: YES
    user_id=80530

    I haven't reviewed the fix, but be sure to
    check it carefully that it preserves the
    same semantics. The difference between
    "invoke" and "eval" is very important,
    especially to be sure that aliases in
    safe interps don't "leak safety".

     
  • miguel sofer
    miguel sofer
    2002-07-29

    Logged In: YES
    user_id=148712

    I'm pretty sure safety has been maintained: I only modified
    AliasObjCmd which processes aliases and never sent the flag
    TCL_INVOKE_HIDDEN to TclObjInvoke.
    TEOVI looks for commands using Tcl_GetCommandFromObj(), so
    essentially using a cached value if (available && valid),
    and looking up by name otherwise. So the issue is: could the
    cmdName object have a cached reference to a hidden command?
    I'll build extra safety and make the Alias structure keep a
    private copy of the targetCmdName object, so that it never
    keeps a foreign cached value.

    BTW, traces on hidden commands are still not being fired ...

     
  • miguel sofer
    miguel sofer
    2002-07-29

    Logged In: YES
    user_id=148712

    OK: if a command is hidden, Tcl_GetCommandFromObj() will
    invalidate any cached reference. It works OK:

    [mig@mini unix]$ ./tclsh
    % proc a {} {puts hello}
    % interp alias {} b {} a
    b
    % b
    hello
    % interp hide {} a
    % b
    ambiguous command name "a": after append array auto_execok
    auto_import auto_load auto_load_index auto_qualify

    Adding this to the testsuite (interp-9.3)

     
  • Don Porter
    Don Porter
    2002-07-31

    Logged In: YES
    user_id=80530

    interesting. I was actually more concerned
    about the arguments, making sure
    that the right ones gets substituted in the
    right interp.

     
    • labels: 105682 --> 46. Traces
     
  • Don Porter
    Don Porter
    2003-06-26

    • assigned_to: msofer --> dgp
     
  • Don Porter
    Don Porter
    2004-07-13

    • assigned_to: dgp --> msofer
     
  • Don Porter
    Don Porter
    2004-07-13

    Logged In: YES
    user_id=80530

    Anything left to resolve here,
    or can we close this?

     
  • miguel sofer
    miguel sofer
    2004-07-13

    • status: open-fixed --> closed-fixed