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