Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-719790 ] fcopy -command hangs in Win NT4
|
From: SourceForge.net <no...@so...> - 2003-11-23 14:11:12
|
Bugs item #719790, was opened at 2003-04-11 09:44 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=719790&group_id=10894 Category: 25. Channel System Group: develop: 8.4.5 Status: Open Resolution: None Priority: 8 Submitted By: Jean-Claude Wippler (jcw) Assigned to: David Gravereaux (davygrvy) Summary: fcopy -command hangs in Win NT4 Initial Comment: Reported by Mads Linden, for tclkit, but I don't think it's tclkit. To reproduce, run tcllib's ftpd server on Windows, fetch a file > 4 Kb. The transfer does not complete. - server has to be Win32 (running tclkit 8.4.2), Linux works - client is Linux in my case (std ftp cmd) - transfer needs to be over 4 Kb, it seems - may also have to be binary (it is, in my case) - ftpd running on server hangs in line 1200, fcopy with -command - i.e. input is file, output is socket - tclkit 8.4.0 and 8.4.1 reported to work ok Hm, this looks like trouble in fcopy. I changed: fcopy $f $data(sock2) -command [list ::ftpd::GetDone $sock $data(sock2) $f ""] to: fcopy $f $data(sock2) ::ftpd::GetDone $sock $data(sock2) $f "" [tell $f] ($f points to a file) And now, the ftp transfer works. The data appears to come across, but the last part does not flush and it ends up deadlocked. If this is the same problem as reported by Mads Linden, then it works ok on 2k, but not XP. I've only run a test on NT4. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-23 06:11 Message: Logged In: NO my notes on the bug: by giving the "-size" to fcopy of the size being send, will make the callback work as expected. this workaround does unfortantly not work when in ftpd: ::ftpd::command::STOR, since the server does not know the size of the incoming file/data. what is wierd is that sometimes it works fine, like yesterday i added an "update" just before fcopy and it worked fine, then the day after it stopped working. i have now seen this bug on 2000,XP Mads ---------------------------------------------------------------------- Comment By: Jean-Claude Wippler (jcw) Date: 2003-11-23 05:36 Message: Logged In: YES user_id=1983 Sorry to keep raising this issue, but tclkit 8.4.5 continues to fail on this case. I can't see how anything in tclkit affects the channel or event systems, so I keep suspecting a weird bug in Tcl which tclkit happens to hit in the above example. The server socket is Windows - that's the one invariant in all this AFAICT. ---------------------------------------------------------------------- Comment By: Jean-Claude Wippler (jcw) Date: 2003-11-10 16:38 Message: Logged In: YES user_id=1983 I'll need to triple-check, but when Andreas worked on it, and when I tried just now, it still hangs. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-11-10 13:11 Message: Logged In: YES user_id=72656 I believe the Andreas fixed this for 8.4.5. ---------------------------------------------------------------------- Comment By: Jean-Claude Wippler (jcw) Date: 2003-09-17 11:25 Message: Logged In: YES user_id=1983 A workaround has been found: provide explicit "-size N" to fcopy ---------------------------------------------------------------------- Comment By: Jean-Claude Wippler (jcw) Date: 2003-05-12 11:45 Message: Logged In: YES user_id=1983 Evrything is ok in ActiveTcl 8.4.2, and in Tclkit 8.4.1, but not in Tclkit 8.4.2. It looks like I'm going to have to fire up my bug buster. Will follow up once this has been resolved. ---------------------------------------------------------------------- Comment By: Jean-Claude Wippler (jcw) Date: 2003-05-12 09:02 Message: Logged In: YES user_id=1983 I'm being told that it also fails on Win2k pro (tclkit 8.4.2, threaded build). Am looking into finding a simpler test case (so far, my tests have been based on running sdx starkit, which has ftpd inside). And whether threads matter... ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2003-04-17 12:17 Message: Logged In: YES user_id=7549 I doubt the current problem came from my changes. All I did was revamp how the message handler window and service thread where brought up and down and changed the winSockProcs prototypes to be more readable. I'm working on a similar problem at the job, but happens to be in the reverse, with files less than 4k don't flush sometimes... A good place to start looking would be the generic layer for how background flushes work and how the watch mask is reset and possibly not turned on again when interest is still desired. How this relates to NT4 only is unknown and I wouldn't be at all surprised if it turned out to be an OS problem that somehow exercises a race condition. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2003-04-14 12:00 Message: Logged In: YES user_id=75003 David, this seems more in your area of expertise. As I also see in the changelog that you did a big revamp of all win channel drivers in general and sockets in particular I have to consider the possibility that these changes introduced the problem (Changelog 2002-11-26/27). My own tests were on a Win2000 system, using it as both client and server. This worked. Another combination was linux lcient, Win2000 server, which also worked. As described in the report I used the standard 'ftp' command as client, for both combinations. For Tcl I used the HEAD of core-8-4-branch (head as of saturday April 12, 2003), and the base-kit we build at AS. The ftpd is 'tcllib/examples/ftpd/ftpd.tcl', slightly modified (different path to the tcllib/modules/ftpd/ftpd.tcl). No locks, no hangs, for files in the range of several hundred k. Getting access to an NT4 machine might be possible here, but is still a tad difficult. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=719790&group_id=10894 |