LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLL throws exception after running many times

Solved!
Go to solution

Thank you Rolf! One thing I'm curious about is that the memory did not seem to explode when I looked at Task Manager, it stayed around 300MB the whole time, does that make sense with your findings?

 

Would it be easy for me to fix these problems (I've never created a DLL in C++ or any other language before) or should I try to get a hold of the original developer?

0 Kudos
Message 11 of 15
(577 Views)

It doesn't quite make sense like that, but then it is C++ and there might be some caveats with respect to that, that might make sure that the lost memory pointer somehow gets deallocated anyhow. I wouldn't really know. It certainly is illegal memory handling and even the best C++ exception handling can not fully fix such blatant abuse.

 

It would be fairly easy to recompile that code but you do need the according project files too and the C compiler version that was used for this. If you have to recreate a project in order to compile this DLL, that is not going to be an easy task if you haven't done C programming and DLL creation before. If you have a chance you definitely should try to get your developer involved and honestly that code as is looks so horribly wrong I doubt it is the version that went into creating your DLL. It should really bomb much earlier already as it violates more things than just creating memory leaks.

Rolf Kalbermatter
My Blog
Message 12 of 15
(572 Views)

I have just finished implementing something similar to Blokk's suggestion. I created a small executable that is like a queued message handler but using network steams (network stream message handler). This executable takes care of interfacing to the DLL. Now after it runs 100 times, I just close it and re-open it and re-establish the network stream. It works pretty well and avoids the exception I was getting earlier. The downside is that every 100th set of data takes about a second longer to send due to restarting the exe, but that should be acceptable.

 

The DLL looks pretty simple, so I wonder if I could just VISA functions for the USB raw data transfer...

0 Kudos
Message 13 of 15
(556 Views)

@Gregory wrote:

 


The DLL looks pretty simple, so I wonder if I could just VISA functions for the USB raw data transfer...


Not likely! This DLL is only a very thin (and badly implemented) wrapper around the CCyUSBDevice class which is part of the Cypress CyAPI USB Device SDK. The real work of handling communication with the device controller is done in the CCyUSBDevice class and its internal classes to handle streams and endpoints and linked into your DLL through CyAPI.lib, which is provded with said SDK.

 

Implementing this properly with separate calls to Open, WriteBulk, and Close functions in the DLL would not only avoid this delay but also speed up overal communication too as you wouldn't have to open and close the device communication for every data chunck, but then it might be that you have to add delays anyhow as the device might be completely overrun by such a massive data stream! Smiley LOL

Rolf Kalbermatter
My Blog
Message 14 of 15
(546 Views)

Ah ok, thanks for sharing all the knowledge!

0 Kudos
Message 15 of 15
(527 Views)