Memory or resource leak on latest version?

[Bill_Texas]

Since my last upgrade, maybe the past month, it seems that the "GDI Object count" for PP has developed a leak on my PC (which is XP). It's a slow leak. When I start PP, with a dozen accounts and thousands of messages, the count is only 160. I have been watching it grow as I used it. At the moment it's up to 1,869.

I keep an eye on it and restart PP from time to time because it steadily grows so high. (Side note, restarting is a lengthy process due to the slower loading of above-1,000 message accounts, and one extremely slower above-10,000 message account. It got much better with one of the releases about a year ago. I'm very happy it handles it well though.)

I have blocked remote images set which may be a factor.

I just opened a message and the count went from 1,869 up to 1,897. I closed it and it went back to 1,869.

I opened another and it went to 1,919. I then double clicked to show the images - just one was revealed, a non animated JPG, about 10% of the size of the screen. The count rose to 1,928. I hit escape to close the message and it returned to 1,896. Note, it did not return to 1,869, even though the image is blocked again from closing the message. Now I clicked the same message and it went to 1,948. Double clicking to reveal the image (which appears to be the same image) rose the count to 1,953. It's creeping higher each time.

I'm calling it a "leak" because over time it keeps rising without returning to the original count.

[Bill_Texas]

I can open and close a message repeatedly without opening any images ever, and the count rises every time.
Start at 369
Opening and closing (no image open) 396
Same message, opening and closing (no image open) 423
Same message, opening and closing (no image open) 450

By the way both Windows 7 and XP task manager let you see GDI objects with View/Select columns.

[Bill_Texas]

I much suspect that the source code is not closing files after opening them, perhaps assuming that the O/S or that under-the-hood compiler-supplied logic will clean up for them ("invisibly"). Once upon a time it was serious business for programmers to release resources and memory when done, but I wonder if that practice is still adhered to.

[spc3rd]

Greetings again, Bill_Texas,

As mentioned in my initial reply to your other topic post, I have contacted Jeff and asked him to review the issues you're reporting, as they will likely require his and other members of the Esumsoft Team expertise to resolve.

Until Jeff and other team members can drop by, please post back with the following:

- Which version of POP Peeper are you currently using?

Much obliged and best regards,

[Bill_Texas]

PP 4.3.0.0
Webmail 4.2.5.0
SS 1.0.1.8
IMAP 4.3.0.0
SendMail 4.3.0.0
Pic 4.1.1.0 (4.3.0.0 latest)
tweak 4.3.0.0

[Jeff]

Ok, it took some time, but I found the problem. And, you're right, the guilty code was introduced in v4.3 (dpi-related code for the toolbar). The exact number of leaked objects is going to vary per computer, but for the message toolbar, it's about 30 objects each time it's opened/closed. The sendmail toolbar is less (about 2). The main toolbar would have the problem, too, but since it's only created once until its destroyed at exit, those leaked objects are insignificant (assuming the OS is doing it's job...).

Anyhoo -- I'm going to make a new build and test to make sure that the leaks are plugged. And if all goes well, I'll try to make a fix available soon.


More info for nerds:
When I started researching this earlier this morning, I came across this thread:
http://stackoverflow.com/questions/1844 ... eir-number

Unfortunately, the OP in that thread is correct, but no one commented on that fact. I tested his code and he's right -- calling CreateSolidBrush() -- which does increase the gdi count -- followed by DeleteObject() does not decrease the gdi count. I extended his code and found that the 2nd call to CreateSolidBrush() does not increase the gdi count; so it seems that Windows is caching the gdi object in case it's used again. It's these kinds of things that make finding gdi leaks particularly nasty.

[Bill_Texas]

Way to go tracking that down!!

Side note, Acronis backup is totally useless on XP because unlike you their programmers are too stupid to understand what a memory or resource leak is, and with Acronis the GDI count rises explosively until crash, every time. I spent hours and days sending them massive loads of evidence, even a movie file, but they simply don't understand resources, and never lifted a finger to repair it. (You'd expect a large commercial company would understand such fundamentals - ha! In their case, every single time a file is opened (which is zillions for a backup) the GDI soars. In short, Acronis crashes XP machines. Isn't that swell, that a critical product like a backup, which you rely on to save your life, has a 100% crash rate.) (It's also an absurdly convoluted design when it works, on Win 7; I strongly recommend avoiding Acronis. They're simply clueless.)

Sorry about that, really hate Acronis and their idiot developers and runaway GDI! Anyway I thought the answer here would be file handles. Well done figuring out the real culprit! Mad debugging skillz. Whether you were lucky or brilliant, keep it up! That kind of thing would stump mere mortals.

[Jeff]

Well, like I said, gdi leaks can be very tricky. In fact, as far as the leak in PP is concerned -- PP was actually trying to release the objects that were causing the leak, but because MS's documentation is so very poor on the subject, PP's attempt was... ill-placed and it was attempting to release objects whose handles had changed since they were created.

Also, something I came across in my earlier research -- there was an MSDN page that was basically a hotfix for [XP and server 2003](?) for gdi leaks. I didn't think much of it at the time since it wasn't what I was looking for. But my point is it's very possible that the issue is in the XP OS and not their software.

Ah, here it is:
https://support.microsoft.com/en-us/kb/319740
ftr, I'm not suggesting this will fix any issues or that you should even install this if you don't already have it. I'm just providing it as reference material.

[Jeff]

I had intended to make the fix available sooner, but I had a hard time remembering to check the final stats before the nightly shutdown... But, of the stats I did manage to collect, the typical number PP rested on was about 300-310.

So, the fix is now available:
http://www.esumsoft.com/pop-peeper-beta/

Let me know if it works better for you.