|
2013-08-15
| ||
| 14:05 | The fix for [3610404] leads to a simplification in the implementation of forward methods. check-in: 1cafa9ed0e user: dgp tags: trunk | |
|
2013-08-14
| ||
| 19:02 | • Closed ticket [3610404fff]: re-resolution gets wrong target plus 9 other cha... artifact: 9d1403c61e user: dgp | |
| 19:01 | [3610404] Re-resolution of command after enter traces invalidate epoch. Make sure context is such th... check-in: c1bc5483be user: dgp tags: trunk | |
|
2013-04-17
| ||
| 03:19 | • Ticket [3610404fff] re-resolution gets wrong target status still Open with 4... artifact: 0bb750c92d user: dgp | |
| 03:12 | • Ticket [3610404fff]: 4 changes artifact: 7b77a058ad user: dgp | |
| 03:07 | • Ticket [3610404fff]: 5 changes artifact: ea96ef4ae5 user: dgp | |
|
2013-04-10
| ||
| 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 | |
|
2013-04-09
| ||
| 18:57 | • New ticket [3610404fff]. artifact: f46067525d user: dgp | |
| 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... | ||||