Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-2569449 ] error with [interp create] in embedded build on Mac
|
From: SourceForge.net <no...@so...> - 2009-10-05 02:42:17
|
Bugs item #2569449, was opened at 2009-02-05 20:23 Message generated for change (Settings changed) made by das You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2569449&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: 50. Embedding Support Group: obsolete: 8.5.6 >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Torsten Berg (treincke) Assigned to: Daniel A. Steffen (das) Summary: error with [interp create] in embedded build on Mac Initial Comment: An embedded build of Tcl/Tk on the Mac (Intel) will fail on this command: % interp create Can't find a usable init.tcl in the following directories: /Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts / Users/Torsten/Tcl/distrib/mac-builds/8.5.6/Applications/Utilities/ This is true for tclsh and wish in the Tcl/Tk versions 8.5.6 and the current development version of 8.6. It worked inall 8.5.x versions until and including 8.5.5 The embedded build was done using the procedure from the README: export ver="8.5.6" export dest="8.5.6" make -C tcl${ver}/macosx/ embedded BUILD_DIR="/Users/Torsten/Tcl/ distrib/mac-builds/${dest}/" INSTALL_ROOT="/Users/Torsten/Tcl/distrib/ mac-builds/${dest}/" make -C tk${ver}/macosx/ embedded BUILD_DIR="/Users/Torsten/Tcl/ distrib/mac-builds/${dest}/" INSTALL_ROOT="/Users/Torsten/Tcl/distrib/ mac-builds/${dest}/" make -C tcl${ver}/macosx/ install-embedded INSTALL_ROOT="/Users/ Torsten/Tcl/distrib/mac-builds/${dest}/" BUILD_DIR="/Users/Torsten/Tcl/ distrib/mac-builds/${dest}/" make -C tk${ver}/macosx/ install-embedded INSTALL_ROOT="/Users/Torsten/ Tcl/distrib/mac-builds/${dest}/" BUILD_DIR="/Users/Torsten/Tcl/distrib/ mac-builds/${dest}/" ---------------------------------------------------------------------- >Comment By: Daniel A. Steffen (das) Date: 2009-10-05 04:42 Message: Committed to HEAD, core-8-5-branch and core-8-4-branch. ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2009-10-05 04:17 Message: bug in 10.4 appears to extend to any CFRelease() of a CFBundle, once that has occurred, any subsequent attempt to recreate a bundle for that location fails. Adapted attached patch to bypass CFRelease() of bundle returned from CFBundleCreate() on 10.4 and earlier. ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2009-09-17 21:10 Message: this appears to be due to a bug in 10.4 CoreFoundation with CFBundle reference counting (CFRetain()ing and then CFRelease()ing a bundleRef obtained from CFBundleGetBundleWithIdentifier() results in that bundle being released and becoming unavailable for the lifetime of the process), the issue is not present on 10.5 or 10.6. patch attached that works around this bug and should fix the problem. ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2009-02-06 23:08 Message: ok, that sounds familiar, I had a similar bug once when a CFBundle owned by CF was over-CFReleased, sounds like I'm doing this here, will look into it, thanks. ---------------------------------------------------------------------- Comment By: Benjamin Riefenstahl (cc_benny) Date: 2009-02-06 22:18 Message: I have the same problem with my builds. I can't see an error in our code. Adding debug output shows that only the first call for the same parameter succeeds, after that the routine does not find the bundle any more (bundleRef is always NULL). Removing the CFRelease(versionedBundleRef) fixes the problem. At least in my environment (OS 10.4.11) I always get back the same reference-counted object so at least here the memory leak would not be a real problem. For now I just removed both the CFRelease and the CFRetain in my sandbox. ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2009-02-05 23:38 Message: that change looks fine, only the CF leak is fixed and some extra NULLity checks added, nothing else changed, so I strongly doubt that this is the cause of the problem at hand... no time to look into it further ATM unfortunately ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2009-02-05 23:16 Message: that commit was supposed to be a pure leak fix, no functionality change: http://fisheye.categorifiedcoder.info/changelog/Tcl/tcl/macosx?cs=MAIN:das:20081207162844 looking over it now to check for any new bugs... ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2009-02-05 22:59 Message: I'm guessing the 2008-12-07 commit to tclMacOSXBundle.c is to blame. Nothing in the ChangeLog about it das? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2009-02-05 22:37 Message: Where is the init.tcl file for Tcl 8.5.6 installed? Has the answer changed since release 8.5.5 ? Has the set of directories on the search path changed since release 8.5.5 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2569449&group_id=10894 |
