Tcl Source Code

View Ticket
The fix for [3610404] leads to a simplification in the implementation of forward methods. check-in: 1cafa9ed0e user: dgp tags: trunk
19:02 Closed ticket [3610404fff]: re-resolution gets wrong target plus 9 other changes artifact: 9d1403c61e user: dgp
[3610404] Re-resolution of command after enter traces invalidate epoch. Make sure context is such th... check-in: c1bc5483be user: dgp tags: trunk
03:19 Ticket [3610404fff] re-resolution gets wrong target status still Open with 4 other changes artifact: 0bb750c92d user: dgp
03:12 Ticket [3610404fff]: 4 changes artifact: 7b77a058ad user: dgp
03:07 Ticket [3610404fff]: 5 changes artifact: ea96ef4ae5 user: dgp
19:28 Ticket [3610404fff]: 4 changes artifact: 437e7201d0 user: dkf
19:25 Ticket [3610404fff]: 4 changes artifact: ddf2bec2be user: dkf
19:20 Ticket [3610404fff]: 4 changes artifact: cdd36f545a user: dkf
16:05 Ticket [3610404fff]: 4 changes artifact: 0b36c82f84 user: dkf
03:09 Ticket [3610404fff]: 5 changes artifact: b743d812fd user: dkf
03:02 Ticket [3610404fff]: 5 changes artifact: 8ed9716c0b user: dkf
02:04 Ticket [3610404fff]: 4 changes artifact: 426ae9f395 user: dgp
18:57 New ticket [3610404fff]. artifact: f46067525d user: dgp

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
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!



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

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) {
+               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.