From: SourceForge.net <no...@so...> - 2012-11-20 08:10:20
|
Bugs item #3588687, was opened at 2012-11-19 22:41 Message generated for change (Comment added) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3588687&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: 39. Package Manager Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Don Porter (dgp) Assigned to: Don Porter (dgp) Summary: Tcl_InitStubs() Broken As Designed Initial Comment: A stubs-enabled extension encounters Tcl in three distinct ways. 1) It compiles against a tcl.h file from some release of Tcl. With USE_TCL_STUBS active, the particular tcl.h file determines the layout of the stubs table that the extension is compiled to assume. 2) It links against some libtclstub.a file. That libtclstub.a file in turn was compiled against some tcl.h file and from it got a value of TCL_STUBS_MAGIC compiled into it. As far as I can tell there is nothing in place to make sure that the two tcl.h files so far mentioned are the same file, or at a minimum define the same TCL_STUBS_MAGIC value. Until now it's never been an issue since we've never changed that value. 3) The extenson [load]s into some Tcl interp. The extension calls Tcl_InitStubs() passing in the interp value. T_IS pulls a table pointer out of the iPtr->stubTable field of that interp for vetting for suitability. What's important is that the table in iPtr->stubTable has a compatible layout to the one that was compiled into the extension. But the mechanism in place cannot check this. To illustrate this, consider compiling an extension containing the call Tcl_InitStubs(interp, "9.0", 0); but compiling it against a Tcl 8 header file, so all of it's other calls into the Tcl library are coded based on the assumptions of the Tcl 8 stub table layout. Next imagine linking this against libtclstubs9.a so that the TCL_STUBS_MAGIC value the Tcl_InitStubs() call will be checking will be the one for the Tcl 9 table. Then [load] in a Tcl 9 interp. All of Tcl_InitStubs() checks will pass, but we'll be left with an extension compiled to Tcl 8 layout expectations making use of a Tcl 9 stub table, and that's gonna crash hard. Now, if the extension writer would have just stuck with the recommended convention of Tcl_InitStubs(interp, TCL_VERSION, 0) he could not get in this trouble. But that is our fault for giving him that knob to tweak in the first place. Tcl_InitStubs ought not have a "version" argument for the coder to get wrong. ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2012-11-20 00:10 Message: Thanks, Don, for this clear description. Regarding the second point, the TCL_STUBS_MAGIC value built-in the stubs library, that's completely right. I already did work on this in the "novem" branch which IMHO corrects that, but feedback is welcome. >What's important is that the table in iPtr->stubTable has a compatible >layout to the one that was compiled into the extension. But the >mechanism in place cannot check this Yes, that's a problem. So, let's put a mechanism in place to check this. Your last point, the version argument, the problem now is that Tcl_InitStubs(interp, "9.0", 0) returns false when called in a "8.6" interpreter. This means that 8.x extensions cannot be used in a 9.0 interpreter. I don't have an immediate solution for that. Easiest is to let extesions use Tcl_InitStubs(interp, "8.6+", 0) if they want to indicate that they can run under both 8.6 and 9.0, but that could - at best - only work on 32-bit platforms. 64-bit platforms should have a different MAGIC value, given the big reform that is being worked on now by dkf. Regards, Jan Nijtmans ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3588687&group_id=10894 |