On Wed, 5 Nov 2008, Andreas Wurf wrote:

> To make it short: I could reproduce my problem (one channel stuck in passive
> mode) with the attached source on windows. But only on approx. every 20th
> test run. And I had to increase the number of files and their size to
> reproduce the error. Maybe we should implement a true dynamic way of faking
> a large number of files with a random size in a well-known range, to make
> this a real stress test.

Today I ran the test from my laptop to my server over my local wifi network
but it seems to behave exactly as it did locally. Possibly this is because the
server is too close. I don't have any other ftp server around that allows
uploads to test with right now.

Anyway, to get back to the problem you see. When it get stuck, isn't it your
app that gets stuck in a select()-loop and it never gets any action on the
socket event it waits for? If so, in what state is the easy handle then? (I
assume you can "attach" a debugger to the running process, like with gdb -p
[pid] or similar).

-- 
  / daniel.haxx.se