Ticket Hash: | 1dc2d851ebd9a3df09dc3cfc96e62db919213a21 | |||
Title: | SEGFAULT by creating of itc-class after deleting of oo::class machinery | |||
Status: | Closed | Type: | Code_Defect | |
Severity: | Critical | Priority: | Immediate | |
Subsystem: | Resolution: | Fixed | ||
Last Modified: | 2019-02-08 23:55:11 | |||
Version Found In: | >= 4.x | |||
User Comments: | ||||
sebres added on 2019-02-08 17:28:24:
(text/x-fossil-wiki)
Itcl seems to have some tcl-oo dependencies now (since some 4th version), so the bug #254 seems to have continuation. Inspired by strange "magic" covered in this itcl-tests by [/artifact?name=a437c1d8c98cbee6&ln=281|sfbug-254] I tried this in tcl-shell (for 8.6 current): <pre> % oo::class destroy % ::itcl::class ::test {} </pre> followed by **BOOM** with panic "alloc: invalid block: 004CB620: 20 0". Doing the same in each child-interp (as it exactly occurs now in itcl-tests sfbug-254 + sfbug-257) is harmless. I still don't know it is oo bug or rather itcl bug. I'd take a look deeper, but ATM it looks like Tcl_DeleteNamespace is an evil-doer, at least I don't see itcl between 2..7 in the call-stack: <pre> #2 0x6d7ea757 in Tcl_Panic () from tcl86 #3 0x6d805d3a in Ptr2Block () from tcl86 #4 0x6d805ee9 in TclpFree.part.2 () from tcl86 #5 0x6d7d4fa5 in TclOODecrRefCount.part.2 () from tcl86 #6 0x6d7d6285 in ObjectNamespaceDeleted () from tcl86 #7 0x6d7d0779 in Tcl_DeleteNamespace () from tcl86 #8 0x67f6eb6a in ItclClassBaseCmd.part.5 () from itcl412 </pre> sebres added on 2019-02-08 19:27:11: (text/x-fossil-wiki) Further related case (one could already guess): <pre> % oo::class destroy % load {itcl412} itcl </pre> causes segfault too (don't see any panic at the moment). sebres added on 2019-02-08 23:55:11: (text/x-fossil-wiki) Found several other cases (all of those segfaulting due to dependency between itcl- and oo-subsystems). Ultimate fix is provided now in branch [/timeline?r=bug-1dc2d851eb|bug-1dc2d851eb]. Merged into trunk, because this all is to classify as grave resp. critical.<br/> Additionally, I cannot really work on another issue (affecting memory/references subsystems) as long as the whole system is basically unstable. |