From: SourceForge.net <no...@so...> - 2009-02-03 22:21:41
|
Bugs item #2558422, was opened at 2009-02-02 23:01 Message generated for change (Settings changed) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2558422&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 10. Objects Group: development: 8.6b1.1 >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Pat Thoyts (patthoyts) Assigned to: Jan Nijtmans (nijtmans) Summary: const Tcl_ObjTypes breaking stubs contract. Initial Comment: The change to the core Tcl_ObjTypes of 15 Oct 2008 has the return type for Tcl_GetObjType and the storage attribute for the core type structures to const. As noted in the commit comment for some (all?) compilers this will move the storage location in the binary to the TEXT segment so that the structure is truly constant. However, this change critically affects the following extensions: tcom (Windows COM support); tcljava, tclblend, nsjava (all java bridges, possibly all variations on a single code base); combat (CORBA bridge); e4graph. All these extensions use the same technique of overriding the cmdName type to add code to the freeIntRepProc member. These extensions now crash when loaded into an 8.6 interpreter. The reason these extensions do this is to provide for command-like references to things that need cleaning up automatically. I could go on with an explanation of the COM package's use of this but really the main point is that this commit has changed the stubs contract here. Extensions that were fine using stubs with 8.4 and 8.5 now crash with 8.6. Can we have this reverted: C:\opt\tcl\src\tcl.git>git bisect good 63c56af1f8be10728f09ff1d066ec899977d9e16 is first bad commit commit 63c56af1f8be10728f09ff1d066ec899977d9e16 Author: nijtmans <nijtmans> Date: Wed Oct 15 06:17:03 2008 +0000 Add "const" to many internal const tables, so those will be put by the C-compiler in the TEXT segment in stead of the DATA segment. This makes those table sharable in shared libraries. ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2009-02-03 22:36 Message: Thanks, Donal! I fully agree with your analysis and fix. So, closing. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-02-03 19:57 Message: I've applied the simplest possible fix: putting the structure in writable memory (with suitable warning messages in comments). I've also added a proper declaration in tclInt.h (since the structure is theoretically accessed from two files anyway, though the code in tclProc.c is actually commented out at the moment). ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2009-02-03 16:29 Message: I did some tests with tclblend, against Tcl 8.6, and came up with a patch which makes everything compile against Tcl 8.6. See: [tcljava-Patches-2561078] Compile/Run against Tcl 8.6 The way TclBlend should have done it was create a new object type which is a copy of the "cmdName" object type but with different functions. Then every command which needs java functionality can use this new object type in stead of the original "cmdName" type. [tcljava-Patches-2561078] doesn't do that yet, but in stead simply silences the warning. Expect this to be fixed in a few days. Regards, Jan Nijtmans ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2009-02-03 16:14 Message: That's fine with me. I agree that this overriding of core types seems somewhat evil. On the other hand, what else is Tcl_GetObjType for if not to provide for this eventuality. Having dug around in google code a bit it looks like the technique was pioneered by the Feather extension and subsequently picked up by the other extensions listed. In the future it may be worth trying to TIP some kind of official mechanism for this where a limited lifetime command needs to be managed without requiring an explicit delete call. This will have to be a Tcl 9 change though I think. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2009-02-03 10:09 Message: I agree that breaking a stubs contract is crucial, so I will revert the const-ness of the internal Tcl_ObjTypes. However, changing the freeInteRepProc function at runtime is clearly a hack the core should warn about, that's why I prefer to keep the signature of Tcl_GetObjtype as is. If extensions want to use this hack, they can easily fix that with a type cast. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2558422&group_id=10894 |