| Ticket UUID: | 3610404 | ||
| Title: | re-resolution gets wrong target | ||
| Type: | Bug | Created on: | 2013-04-09 18:57:23 |
| Submitter: | dgp | Assigned to: | dgp |
| Subsystem: | 35. TclOO Package | Severity: | Minor |
| Priority: | 5 Medium | Last modified: | 2013-08-14 19:02:42 |
| Status: | Closed | Closed by: | dgp |
| Resolution: | Fixed | Closed on: | 2013-08-14 19:02:42 |
| Version: | current: 8.6.0 | ||
| 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-04-10 02:04:26:
Branch bug-3610404 has the one-liner fix. dkf added on 2013-04-10 03:02:49:
Flushing that cache in that way shouldn't cause that. Ick. 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 16:05:41:
And that appears to be a bug in Tcl 8.5. 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 19:25:41:
And I can't see where it is happening at all. :-( 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.) dgp added on 2013-04-17 03:07:44:
Looks like the problem is refCount management of the commandPtr in the TclEvalObjvInternal() routine. 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:19:14:
committed to core-8-5-branch dgp added on 2013-08-14 19:02:42:
Finally getting back to closing this... | ||||