I had a customer report a server crash caused by running out of memory after deleting lots of archives.  I tried running my application under BoundsChecker, and after deleting a single archive, I saw 1,455 memory leaks totalling 157,856 bytes.  After deleting 100 archives, I saw 38,330 memory leaks totalling 6,810,443 bytes.  (The top 3 were 19,438 leaks totalling 4,607,744 bytes from FPOS2.dll, 10,207 totalling 502,511 bytes from FPUtils.dll, and 8,295 totalling 1,755,723 bytes from FPCore.dll.)

I was using SDK version 3.2 Patch 1.  I just tried this again with 3.2 Patch 3, and saw the same results.

As a test (and to verify that it's not a coding problem on my end), I modified the distributed 'GetClusterInfo" sample to take an optional numeric parameter, and to run everything from the FPPool_SetGlobalOption() through the FPPool_Close() in a loop.  Running it under BoundsChecker for a single iteration showed 475 leaks totalling 57,319 bytes.  Running it for 100 iterations showed 1,267 leaks totalling 93,716 bytes.

There was also a large number of resource leaks reported, mostly from InitializeCriticalSection and InitializeCriticalSectionAndSpinCount.

(Incidentally, the release notes with the latest patch mentioned PDB files, but I didn't see them in the Win32 download?)