Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-1468291 ] Threads: "called Tcl_Close on channel with refCount > 0"
|
From: SourceForge.net <no...@so...> - 2006-05-26 19:44:32
|
Bugs item #1468291, was opened at 2006-04-11 02:03 Message generated for change (Comment added) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1468291&group_id=12997 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: 75. wish Group: current: 8.4.13 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeffrey Hobbs (hobbs) Summary: Threads: "called Tcl_Close on channel with refCount > 0" Initial Comment: When using vfs::mk4 and [file copy] and multi threading on Windows, wish crashes with the error message: "called Tcl_Close on channel with refCount > 0" This issue applies only to the wish application or tclkit on windows. Tclsh and tclkitsh on windows are not affected. When using [file copy] on normal non-vfs directories, everything is fine as well. Only with *non-existing* vfs directories mounted via vfs::mk4::Mount (or maybe other vfs::*::Mount's) the crash appeared to me. I've written a short script which makes it easy to reproduce the bug: # channel refcount bug package require Thread catch {console show} set T [thread::create -preserved] thread::send $T [list set D [file dirname [info script]]] set script { package require vfs::mk4 set logOpen 0 proc ::Log {msg} { if {$::logOpen} { set mode a } else { set mode w set ::logOpen 1 } set L [open [file join $::D log.txt] $mode] puts $L $msg close $L } Log $D set src [file join $D test.txt] set tdir [file join $D tdir.kit] set dest [file join $tdir test.txt] Log $dest Log 1 set vfsh [vfs::mk4::Mount $tdir $tdir] Log 2 file copy $src $dest Log 3 vfs::mk4::Unmount $vfsh $tdir Log 4 } thread::send -async $T $script # end channel bug script When the directory exists, the crash does not happen, but the script runs only until "Log 2". It is not very clear to me whether this is a bug in Tk (because it only appears with wish/windows) or vfs or metakit. ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-26 12:44 Message: Logged In: YES user_id=72656 Applied to VFS. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2006-05-23 13:53 Message: Logged In: YES user_id=32170 The workaround patch looks just fine to me (and indeed it does seem like a weird thing to have to do to deal with Tcl's behaviour). Vince. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-09 22:54 Message: Logged In: YES user_id=72656 OK, I believe that I have found a work-around in vfs. While you might be tempted to call this a vfs bug, it really is more of having to deal with sneaky (stupid) std channel auto-inheritance issues by the Tcl core. The problem is that vfs uses Tcl_DetachChannel - but this is specifically proscribed for std channels (which we only get due to wacky core semantics). Attached is a patch against vfs that checks if we are dealing with a std channel and reverses the auto-inheritance magic by setting the std channel in question to NULL and unregistering it with NULL interp to just decr the refcount, then doing the detach. Passing to Vince to vet and approve. It does correct the reported bug. I suspect it may correct some other wackiness we've seen with vfs-related early open file issues. Again, I consider this a core misfeature, but this is a valid work-around. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-09 22:06 Message: Logged In: YES user_id=72656 I have confirmed that it is the std channel inheritance magic that is the problem. This would best be removed for 8.5, but that would require the ability to enforce a new channel as a std channel from Tcl. BTW, the issue with only running to "Log 2" is that you don't use [file copy -force $src $dest], so it will fail at that point if you've successfully run once. I've attached a more elaborate test script. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-09 20:50 Message: Logged In: YES user_id=72656 OK, I have found that it is likely an issue with Tcl's channel inheritance into std channels. A work-around would be to add: set fake_stdin [open NUL: r] set fake_stdout [open NUL: w] set fake_stderr [open NUL: w] at the start of the script you pass to the thread. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-09 17:24 Message: Logged In: YES user_id=72656 A stack trace, fwiw: Tcl_Panic(const char * 0x100b342c) line 134 + 13 bytes Tcl_Close(Tcl_Interp * 0x00d27318, Tcl_Channel_ * 0x011f8e30) line 2582 + 10 bytes TclCrossFilesystemCopy(Tcl_Interp * 0x00d27318, Tcl_Obj * 0x011c1038, Tcl_Obj * 0x00d30300) line 3683 + 13 bytes CopyRenameOneFile(Tcl_Interp * 0x00d27318, Tcl_Obj * 0x011c1038, Tcl_Obj * 0x00d30300, int 0x00000001, int 0x00000000) line 678 + 17 bytes FileCopyRename(Tcl_Interp * 0x00d27318, int 0x00000004, Tcl_Obj * const * 0x00d340a0, int 0x00000001) line 166 + 38 bytes TclFileCopyCmd(Tcl_Interp * 0x00d27318, int 0x00000004, Tcl_Obj * const * 0x00d340a0) line 85 + 19 bytes Tcl_FileObjCmd(void * 0x00000000, Tcl_Interp * 0x00d27318, int 0x00000004, Tcl_Obj * const * 0x00d340a0) line 868 + 17 bytes TclEvalObjvInternal(Tcl_Interp * 0x00d27318, int 0x00000004, Tcl_Obj * const * 0x00d340a0, const char * 0x00000000, int 0x00000000, int 0x00000000) line 3087 + 25 bytes TclExecuteByteCode(Tcl_Interp * 0x00d27318, ByteCode * 0x00d29f18) line 1419 + 33 bytes TclCompEvalObj(Tcl_Interp * 0x00d27318, Tcl_Obj * 0x00d30108) line 981 + 13 bytes Tcl_EvalObjEx(Tcl_Interp * 0x00d27318, Tcl_Obj * 0x00d30108, int 0x00000000) line 4051 + 13 bytes Tcl_CatchObjCmd(void * 0x00000000, Tcl_Interp * 0x00d27318, int 0x00000003, Tcl_Obj * const * 0x00d34094) line 248 + 18 bytes TclEvalObjvInternal(Tcl_Interp * 0x00d27318, int 0x00000003, Tcl_Obj * const * 0x00d34094, const char * 0x00000000, int 0x00000000, int 0x00000000) line 3087 + 25 bytes TclExecuteByteCode(Tcl_Interp * 0x00d27318, ByteCode * 0x00c768e0) line 1419 + 33 bytes Tcl_ExprObj(Tcl_Interp * 0x00d27318, Tcl_Obj * 0x00d30210, Tcl_Obj * * 0x00f6f978) line 832 + 13 bytes Tcl_ExprBooleanObj(Tcl_Interp * 0x00d27318, Tcl_Obj * 0x00d30210, int * 0x00f6f9a0) line 4431 + 17 bytes Tcl_IfObjCmd(void * 0x00000000, Tcl_Interp * 0x00d27318, int 0x00000003, Tcl_Obj * const * 0x00f6fbbc) line 210 + 23 bytes TclEvalObjvInternal(Tcl_Interp * 0x00d27318, int 0x00000003, Tcl_Obj * const * 0x00f6fbbc, const char * 0x00cf85bd, int 0x0000031d, int 0x00000000) line 3087 + 25 bytes Tcl_EvalEx(Tcl_Interp * 0x00d27318, const char * 0x00cf85b8, int 0x00000322, int 0x00020000) line 3690 + 36 bytes THREAD263! 00e52500() ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-09 17:19 Message: Logged In: YES user_id=72656 OK - figured out some issues. If test.txt doesn't exist, then you just hang on the 'file copy' ... oddly, it isn't just giving an error. When I finally created that file, I was able to see the error. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-09 16:57 Message: Logged In: YES user_id=72656 When building Tcl/Tk 8.5 from CVS head and using the Thread and vfs modules from ActiveTcl 8.4.13 (threaded) on Windows, I am not able to reproduce any crashes. Note that when I originally tried against 8.4.13 with a slightly older pre-build, I did crash with a Tcl_HashTable entry panic. I did resolve that issue in the Thread code already, but it is post-2.6.3, just in CVS. Can you please confirm the exact ChangeLog level of your build chain? ---------------------------------------------------------------------- Comment By: Carlos Tasada (ctasada) Date: 2006-05-09 09:02 Message: Logged In: YES user_id=340696 I think that I don't need the TCLLIBPATH since the auto_path variable is correctly set. Anyway I did and I got the same result. If I do a "package require vfs" in the script it works correctly, but if I do the same inside the thread it cannot be found. And the strangest part is when I do the same with wish and it can find the vfs, but then crashes with the "called Tcl_Close on channel with refCount > 0" Can you reproduce this behaviour in your system? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-05-09 08:46 Message: Logged In: YES user_id=80530 No that doesn't help. :D To test with ActiveTcl 8.5, be sure your TCLLIBPATH environment variable is set so it can find all the packages that got installed with your ActiveTcl 8.4. ---------------------------------------------------------------------- Comment By: Carlos Tasada (ctasada) Date: 2006-05-09 06:02 Message: Logged In: YES user_id=340696 I've just tried the same code in the ActiveTcl 8.5b5 base executable without Tk (base-tcl8.5-thread-win32-ix86.exe) And I get the next error: can't find package vfs while executing "package require vfs" (file "c:/Tcl/bin/base-tcl8.5-thread-win32-ix86.exe/lib/vfs/mk4vfs.tcl" line 21) invoked from within "source c:/Tcl/bin/base-tcl8.5-thread-win32-ix86.exe/lib/vfs/mk4vfs.tcl" ("package ifneeded vfs::mk4 1.10" script) invoked from within "package require vfs::mk4" Hope it helps. ---------------------------------------------------------------------- Comment By: Carlos Tasada (ctasada) Date: 2006-05-08 05:47 Message: Logged In: YES user_id=340696 I've exactly the same problem running the ActiveTcl 8.5b5 (ActiveTcl8.5.0.0b5.261540-win32-ix86-threaded.exe) Running from a clean installation. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-04-12 08:17 Message: Logged In: YES user_id=80530 there are few differences between wish and tclsh+[package require Tk] and [console] is one of them. [console] also does channel stuff, so seemed like a good candidate for the blame, but sounds less likely now. some stack tracing and looking into tclvfs, mkfs, et.c are in order. ---------------------------------------------------------------------- Comment By: Eckhard Lehmann (ecky-l) Date: 2006-04-12 00:31 Message: Logged In: YES user_id=1345135 It has no effect. I doubt that it has to do with the builtin console at all (although I don't know). My intention is that it is more a problem of vfs channels plus channel handling in wish. I should post the bug in the starkit mailing list as well and see what JCW says. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-04-11 11:41 Message: Logged In: YES user_id=80530 Please try replacing catch {console show} with catch {rename console {}} and see what effect that has. ---------------------------------------------------------------------- Comment By: Eckhard Lehmann (ecky-l) Date: 2006-04-11 09:38 Message: Logged In: YES user_id=1345135 All of it was done with the recent ActiveTcl 8.4.12, which includes all the corresponding packages. I believe: - Tcl and Tk are version 8.4.12 (ActiveTcl). - vfs version 1.3 - vfs::mk4 version 1.10 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-04-11 05:13 Message: Logged In: YES user_id=80530 Need version numbers on all software involved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1468291&group_id=12997 |