#5226 forwards clash with execution traces

current: 8.6.0
open
5
2013-04-09
2013-04-09
Don Porter
No

oo::object create foo
oo::objdefine foo {
method target {} {puts Hit!}
forward bar my target
}
proc harness {} {
foo target
foo bar
}
proc handle {cmd args} {
puts "Command [lindex $cmd 0] resolves to:"
puts "\t'[uplevel 1 [list ::namespace which -command [lindex $cmd 0]]]'"
puts "\t\tResolved at level [uplevel 1 {info level}]"
}
trace add execution harness enterstep handle
harness

Output:

Command foo resolves to:
'::foo'
Resolved at level 1
Command puts resolves to:
'::puts'
Resolved at level 2
Hit!
Command foo resolves to:
'::foo'
Resolved at level 1
Command my resolves to:
''
Resolved at level 1
Command puts resolves to:
'::puts'
Resolved at level 2
Hit!

The problem is that [my] is an execution-trace-able
command, but the context in which it is executed
does not match the expectations of execution trace
handlers. The CallFrame establishing the namespace
context for command resolution is missing.

Discussion

  • Don Porter

    Don Porter - 2013-04-09

    The simple-minded fix -- put in the missing push/pop of
    a stack frame -- makes the oo part of the test suite *very*
    unhappy.

     
  • Don Porter

    Don Porter - 2013-04-09

    Alternative approach might be to declare
    that forwards are special in some way, and
    ought to be invisible to execution tracing,
    and that's the real bug to fix.

    Would want to check how ensemble and
    alias redirection behave on that matter.

     
  • Donal K. Fellows

    • priority: 5 --> 3
     
  • Donal K. Fellows

    The bug is in the implementation of the specific execution trace; it is assuming that it can resolve the command simply. This is not necessarily true of any command that is invoked via TclNREvalObjv, as that interface allows the supply of the resolved command. Pushing an extra frame just to make your traces happy is very expensive for everything else (and likely to run into all sorts of problems with the extra frame to pass over in [uplevel]/[upvar]).

    Very tempted to close as a Wont Fix. It's certainly not a high priority to tinker with.

     
  • Don Porter

    Don Porter - 2013-04-09

    Potential defects in the TclNREvalObjv interface
    is exactly the issue I'm investigating.

     
  • Don Porter

    Don Porter - 2013-04-09
    • priority: 3 --> 5
     

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

Sign up for the SourceForge newsletter:





No, thanks