09-12-2017 03:05 PM
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?
09-12-2017 03:13 PM
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.
09-12-2017 06:25 PM
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...
09-13-2017 01:43 AM - edited 09-13-2017 01:58 AM
@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!
09-13-2017 09:07 AM
Ah ok, thanks for sharing all the knowledge!