FlashFXP Forums - View Single Post

Yil · 03-29-2010, 06:02 PM

I learned a thing or two about how to get the thread ID that holds a lock and using that examined some old minidumps of the lockup bug I had from years ago and discovered something weird. The thread holding the loader lock isn't an ioFTPD created thread (they are all accounted for) and it isn't in the minidump which I presume means it exited without releasing the lock and without calling the ioFTPD CrashLog code (the minidumps were created manually).

Since it isn't an ioFTPD thread it's harder to debug since I'm not sure how I would try to even catch it's creation/exiting since the normal uncaught exception handler that should be called clearly wasn't. I'm guessing it's a winsock thread of some sort, but for the moment it appears to make the most sense to switch over to openSSL as soon as possible to try to remove all that MS encryption library crap that might be causing problems and we don't want to use long term anyway...

P.S. Silly, others. The windbg !locks command is useful only against full minidumps. Tinydump's simply don't include the memory regions that extension scans to enumerate critical sections. So, I'll need the full size large dumps rar'd or zip'd please.

The only other thing I might look into is knowing the lockup bug is caused by a thread that exited without releasing the lock, I might just try to find a way to force the freeing of the lock somehow and then suicide...

03-29-2010, 06:02 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	I learned a thing or two about how to get the thread ID that holds a lock and using that examined some old minidumps of the lockup bug I had from years ago and discovered something weird. The thread holding the loader lock isn't an ioFTPD created thread (they are all accounted for) and it isn't in the minidump which I presume means it exited without releasing the lock and without calling the ioFTPD CrashLog code (the minidumps were created manually). Since it isn't an ioFTPD thread it's harder to debug since I'm not sure how I would try to even catch it's creation/exiting since the normal uncaught exception handler that should be called clearly wasn't. I'm guessing it's a winsock thread of some sort, but for the moment it appears to make the most sense to switch over to openSSL as soon as possible to try to remove all that MS encryption library crap that might be causing problems and we don't want to use long term anyway... P.S. Silly, others. The windbg !locks command is useful only against full minidumps. Tinydump's simply don't include the memory regions that extension scans to enumerate critical sections. So, I'll need the full size large dumps rar'd or zip'd please. The only other thing I might look into is knowing the lockup bug is caused by a thread that exited without releasing the lock, I might just try to find a way to force the freeing of the lock somehow and then suicide...