Tcl Source Code

View Ticket
Login
Ticket UUID: 3610404
Title: re-resolution gets wrong target
Type: Bug Version: current: 8.6.0
Submitter: dgp Created on: 2013-04-09 18:57:23
Subsystem: 35. TclOO Package Assigned To: dgp
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2013-08-14 19:02:42
Resolution: Fixed Closed By: dgp
    Closed on: 2013-08-14 19:02:42
Description:
Here's the real bug I've been striving to demonstrate,
recording mismatches with exec tracing capability
along the way.

oo::object create foo
oo::objdefine foo {
    method target {} {puts Hit!}
    forward bar my target
    method bump {} {
        set ns [info object namespace ::foo]
        rename ${ns}::my ${ns}::
        rename ${ns}:: ${ns}::my
    }
}
proc harness {} {
    foo target
    foo bar
}
proc handle {cmd args} {
    foo bump
}
trace add execution harness enterstep handle
proc my {method} {
    puts Missed!
}
harness

Output:

Hit!
Missed!

The re-resolution of "my" happens in the wrong
context.

Comparing with the machinery in [tailcall], I think
this one has a simple fix.
User Comments: dgp added on 2013-08-14 19:02:42:
Finally getting back to closing this...

dgp added on 2013-04-17 03:19:14:
committed to core-8-5-branch

dgp added on 2013-04-17 03:12:30:
Here's the patch:

Index: generic/tclBasic.c
==================================================================
--- generic/tclBasic.c
+++ generic/tclBasic.c
@@ -3650,10 +3650,11 @@

        if (cmdEpoch != newEpoch) {
            checkTraces = 0;
            if (commandPtr) {
                Tcl_DecrRefCount(commandPtr);
+               commandPtr = NULL;
            }
            goto reparseBecauseOfTraces;
        }
     }

dgp added on 2013-04-17 03:07:44:
Looks like the problem is refCount management
of the commandPtr in the TclEvalObjvInternal() routine.

dkf added on 2013-04-10 19:28:02:
(There's a list inside AppendPrintfToObjVA that should only have a single reference to it and which should — in this case — end up with four elements in it, and which is never passed externally, but it is ending up with two references and 5 elements, at which point Tcl_ListObjAppendElement gets rightfully upset. Real WTF moment.)

dkf added on 2013-04-10 19:25:41:
And I can't see where it is happening at all. :-(

dkf added on 2013-04-10 19:20:37:
The 8.5 crash seems to be an "impossible" case. Memory corruption suspected.

dkf added on 2013-04-10 16:05:41:
And that appears to be a bug in Tcl 8.5.

dkf added on 2013-04-10 03:09:09:
And the new tests cause a panic under 8.5!

  Tcl_ListObjAppendElement called with shared object

That bumps it right to highest priority.

dkf added on 2013-04-10 03:02:49:
Flushing that cache in that way shouldn't cause that. Ick.

dgp added on 2013-04-10 02:04:26:
Branch bug-3610404 has the one-liner fix.