FlashFXP Forums - View Single Post

Yil · 01-13-2008, 10:01 PM

I've never had my local copy of ioFTPD running on XP lockup but it doesn't get abused. On the other hand a quad processor 100mbit w2k3 system does lockup on me from time to time and I've got a few memory snapshots of that happening.

Usually you can tell by users with idents or hostnames in their hostmask not being able to login but *@IP.* can, or the system not giving out directory listings or transferring files. At that point you'd think a thread that attempts to dereference the NULL pointer should crash the whole program and trigger a dump (that's what site chrashnow does), but it is so hosed that doesn't work so that proves to me that an internal windows library lock (my guess is ldr_lock from the dump info) is being corrupted or abandoned but I don't know why...

It doesn't help that the windows socket library creates threads on it's own and tries to load/unload dlls and both of those actions acquire the ldr_lock and get stuck... I'm guessing that's involved in the race condition but debugging that is really tricky.

I don't think there were any changes from 5.8.5r to now regarding .ioFTPD files. In fact, I believe you can take a 6.3.5 executable and run it against a 5.8.5r .ini file and it will still run fine. If you make use of newer features such as shared section credits and stuff like that you won't be able to run 5.8.5r obviously but I've really tried to keep it backward compatible with everything optional... Relative symbolic link evaluation is different now though because it was incorrect before but they weren't widely used...

01-13-2008, 10:01 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	I've never had my local copy of ioFTPD running on XP lockup but it doesn't get abused. On the other hand a quad processor 100mbit w2k3 system does lockup on me from time to time and I've got a few memory snapshots of that happening. Usually you can tell by users with idents or hostnames in their hostmask not being able to login but @IP. can, or the system not giving out directory listings or transferring files. At that point you'd think a thread that attempts to dereference the NULL pointer should crash the whole program and trigger a dump (that's what site chrashnow does), but it is so hosed that doesn't work so that proves to me that an internal windows library lock (my guess is ldr_lock from the dump info) is being corrupted or abandoned but I don't know why... It doesn't help that the windows socket library creates threads on it's own and tries to load/unload dlls and both of those actions acquire the ldr_lock and get stuck... I'm guessing that's involved in the race condition but debugging that is really tricky. I don't think there were any changes from 5.8.5r to now regarding .ioFTPD files. In fact, I believe you can take a 6.3.5 executable and run it against a 5.8.5r .ini file and it will still run fine. If you make use of newer features such as shared section credits and stuff like that you won't be able to run 5.8.5r obviously but I've really tried to keep it backward compatible with everything optional... Relative symbolic link evaluation is different now though because it was incorrect before but they weren't widely used...