Call Library Function calling a DLL runs for 3969 loops every time then crashes

[decroosj]

The call library functions work quite well - for exactly 3969 times, then nothing. Only a re-boot of the machine will correct for an additional 3969 loops.

Has anyone had this issue with the call library / DLL application?

Thank you in advance for any help -

PS> The DLL I am using is WAGO's MBT.dll which interfaced quite well to the call library functions.

[Dynamik]

Hi decroosj,

Although I haven't used this DLL, maybe some general checks will produce a cure...

I would meticulously double-check that the data-types passed-in and out, match the function prototype.  Also, carefully review the DLL usage instructions to make sure you're using the DLL correctly and haven't omitted an applicable "close" operation (like "MBTDisconnect".)

Sounds like the dreaded "memory leak" - have you watched "Mem Usage"`in the Task-Manager while looping?

Cheers.

Message Edited by Dynamik on 04-19-2006 02:55 AM

[shoneill]

Ok,

Just a wild input here, but 3969 is one more than 31*128, so maybe the number 32 is the key here?

Are you inputting any index values which are limited to certain ranges?

Are you doing batches of 128 perhaps, and on the 32nd run it crashes?

As I said, just a wild guess, but maybe the number does actually mean something.....

Shane.

[Dynamik]

Nice (amazing) observation, Shane. 

[decroosj]

Thank you for your reply Shane,

I forced the loop to contiunue by means of ignoring errors - the function works properly again at loop 7940, then again at 15876 etc... all for exactly 3969 loops, then some more errors.

I have contacted WAGO - WAGO has mentioned the MBT.dll I was using had some memory leakage problems, so they sent me a new DLL. The new DLL does the same thing.

Some answers:

>>Are you inputting any index values which are limited to certain ranges?
I have checked the call library function against an example sent to me by WAGO and all data types are identical to WAGO's call library function.

>>Are you doing batches of 128 perhaps, and on the 32nd run it crashes?
No, just running the Init-Connect-Disconnect-Exit functions in series in a loop to test for stability. (or in this case in-stability).

Thank you for your valued input here -

John

[shoneill]

I don't think it's a memory leak problem because this tends to lead to a finally crashed DLL.  If the error is created by a memory leak and the error is simply ignored, then the following iterations should NOT work.  At least this is MY understanding of it.

I still think there's a problem with an indexing element, possibly within the DLL code, but this is an easy claim to make, and a very difficult one to test.

Do I understand that you have 3670 >good< runs, then 3670 >bad< runs and so on and so forth?

Can you reproduce the behaviour on another machine?

Wierd.

Shane.