Memory leak?

[klcmay]

Hi all,

My main requirement is to take 5 small images (around 10x10 pixels) that are displayed on the screen (in different locations) and match these to a bank of 60 "known" images. There will always be a match. I then must repeat the process every few seconds indefintiely.

I previously raised another issue with this as GetRectChecksum behaviour appears to differ between MS 9 and MS10 although this is potentially an operating system issue (see http://www.mjtnet.com/forum/viewtopic.p ... ctchecksum for more details of this)

Because of this limitation I have been doing some further testing to try to ascertain the best method of image recognition. In doing this I think I have come accross a possible memory leak which is illustrated by the following macro. I only noticed this when MS crashed mid macro. Running it again I was viewing task manager and could see that the amount of free memory was going down at an alarming rate (~150k per sec)

Let>Hashlib=C:\hashlib\HashLib.dll
Let>y1=0
Let>y2=10
Let>x1=0
Let>x2=10

getTime>a

Let>z=0
Repeat>z
Let>z=z+1
ScreenCapture>%x1%,%y1%,x2%,%y2%,C:\capture.bmp
LibFunc>Hashlib,FileMD5,r1,C:\capture.bmp,buf
Mid>r1_2,1,r1,hash1
if>hash1=9CE3E8216BD03E91EF0C51FC5B0F3AB6
Let>xx=true
else
Let>xx=false
endif
Until>z=10000
getTime>b
MessageModal>%a% %b%

I presume that this is because the hashlib dll is loaded once for each iteration of the loop. However, I am no expert in this area so I would be grateful for some advice and hopefully a workaround/fix.

You may be interested in my findings so far:

1) getRectChecksum is roughly 10 times slower than saving the image and then checksumming it with hashlib. I was very surprised by this as I thought the disk operations would be much more expensive than an in-memory checksum algorithm. Also there is a serious limitation to this method as it also includes the screen co-ordinates (see my other post) which means that I cannot use it easily anyway.
2) MD5 and SHA1 hashes operate in almost the same time for small images
3) Compare bitmaps is roughly 10 times faster than using hashlib (so 100 times faster than getRectChecksum). However if you grab an image from the screen and have 60 images you want to compare against you need to do each one in turn which will, in the worst case sceanrio, mean that it actually takes much longer. There may be ways of narrowing down the number of images to check through but I haven't started thinking about this.

The performance of using ScreenCapture and then hashlib is OK for me (at about 0.018s per image on my system) but I cannot live with the memory issue as my system breaks very quickly.

Any thoughts? Ideas? Alternatives?

Many thanks,

Ken

[Marcus Tettmar]

Without having looked in detail my money is on there being a memory leak inside hashlib.dll rather than a problem with Macro Scheduler itself. I'll take a more detailed look.

[Marcus Tettmar]

Well it didn't take long to spot a potential problem inside hashlib.dll. An object is not being freed. So that could well be the cause of the memory leak you have noticed. I've fixed that and uploaded the new version. Please download hashlib again from:

http://www.mjtnet.com/software/HashLib.zip

Make sure you overwrite your existing hashlib.dll with the new one, dated today 2nd July. Then run your test script and let me know if the memory leak is now gone.

[klcmay]

Sorry - problem is still there.

Prior to running:
354208 k free Physical Memory (I think I need to reboot to recover the memory lost in earlier tests I should have 4 times this!)

After 10,000 iterations:
306640 k free Physical Memory

Thanks for the swift response. Most appreciated.

Ken

[Marcus Tettmar]

I've run your script and I also see a memory leak with the Hashlib function. When I comment out the LibFunc line it goes away. I've also tried running simple functions in other DLLs instead of the hashlib call and the memory usage remains constant. Therefore I am satisfied that there is clearly a memory leak in hashlib.dll but no problem with Macro Scheduler itself. We'll continue to debug hashlib.dll and see if we can find the cause.

[Marcus Tettmar]

Ok, please try again:

http://www.mjtnet.com/software/HashLib.zip

Make sure you overwrite your copy with the latest version. The text file mentions version 1.2

[klcmay]

Thanks very much for this. Hope you manage to find it easily... I know how problematic getting to the bottom of a leak can be from first hand experience!!!

Thanks again.

Ken

[klcmay]

Wow - our last messages crossed... didn't expect you to have solved it so quickly!

Everything seems to work fine now and I can see the memory constantly varying as it is allocated and then freed.

Thanks very much for this. Great job and superb turn around time!

Ken