The report of the memory leak with MSVC8 caused quite some interest in Boost.Dev list; DateTime library was patched to work around this bug, but numerous other libraries are also affected by this, notably lexical_cast and program_options. Since patching MSVC CRT requires rebuilding the DLL, it's easier / more convenient to patch Boost libraries instead for the time being, until Microsoft releases official update. Considering that Boost 1.34 is expected to be released within a month, hopefully all the issues will be cleared up by then.

I discovered an issue in Utils::getFileSize() method which reported wrong size on Windows when the file size exceeded 4gb. The issue was usage of stat() method, which uses 64bit offsets on Unix when _FILE_OFFSET_BITS is defined as 64, but was using 32bit offsets on Windows. The fix was to use _stat64 on Windows. This bug caused all Bittorrent downloads which included files of size >4gb to become auto-paused with message 'out of disk space'.

I have also been working on thread-safe version of SharedFile::read(). The issue there is that when completing file, the file is moved from temp to incoming, and read operations while moving is in progress, or after the moving has been finished, but SharedFile::m_location hasn't been updated yet, fail, causing the SharedFile object to be destroyed, which under some circumstances can lead to crashes in hncore/bt/files.cpp. The solution was to use boost::recursive_mutex::scoped_try_lock in SharedFile::read() (try-lock so as to not block the main thread), and scoped_lock in MoveWork::process to syncronize the operations and throw E_TRYAGAIN error from SharedFile::read() in this scenario. Plugins handle this exception and re-try reading from the file in a few seconds. However, since the code hasn't been fully tested yet, it's not in SVN (not that SVN would be up, anyhow).

Last night I spent about 6 hours with our designer, working on icons for the GUI. So far, the results are 5 black&white base shapes, onto which we hope to add some style and effects tonight.

The 'zombie' clients count reported by 'ed2k deadsource' command was somewhat off originally, displaying too large (up to 60%) amount of 'zombie' clients. Largely, those were false positives, the m_lastAsked variable wasn't updated in all situations. After fixing that variable, I'm seeing around 10% of dead sources (272 out of 2351), which is more realistic. The most common cause for clients to become 'zombie' is that the connection is cut some time during handshaking, and we don't handle all these situations gracefully yet. Due to the large amount of time required to test and analyze these clients (1-2h runtime is minimum required for them to show up in the first place), this is very time-consuming process.

More on the GUI side - I managed to cut 8 pixels from each side of the GUI, winning total of 16px space in width and height. We also tested (for a moment) 24x24px icons on toolbar, but discarded the idea quickly - this interface seems to be heading towards very compact, spartan interface, where every pixel is carefully considered, and wasting 8px height just to have larger icons doesn't sound like good use for space. It's also expected that the filter-box on top-right will disappear after-all, and become more like firefox's "find-as-you-type" feature, since the practical usefulness of the filtering is near-zero, but it should exist nonetheless.

Madcat.