LabVIEW
DLL throws exception after running many times
Solved!
Thank you, great idea! But, my attempt at it did not give any different results. I run this code once with "Unload DLL?" set to false to send the data, then again with "Unload DLL?" set to true. Still after about 200 runs with my data, I get the same error from the DLL.
@Gregory wrote:
Thank you, great idea! But, my attempt at it did not give any different results. I run this code once with "Unload DLL?" set to false to send the data, then again with "Unload DLL?" set to true. Still after about 200 runs with my data, I get the same error from the DLL.
This is most likely not really something you should be trying to solve from LabVIEW. If the DLL bombs somehow, all you can do from within LabVIEW is finding out that it does, nothing more. The correct course of action is to debug the DLL itself and find out why it crashes.
That all said I wonder about the -1 in the length from the PLUT Data. That doesn't quite make much sense, unless the function treats this (incorrectly) as number of character bytes to store into the buffer and then appends an extra NULL byte to terminate the string. A horrible way of dealing with a string buffer in C. If it is a string that you pass into the function, then the length passed in is even more wrong as LabVIEW strings don't have a terminating NULL byte at all and the according array length node will consequently return one byte less than there was actually passed into the VI in the string. And things get definitely very awry if you pass in an empty string: The resulting length passed into the DLL function will be then -1 and if the DLL treats this in reality as an unsigned integer it will see a whooping 0xFFFFFFFF or 4 billion bytes of buffer length.
@Minions wrote:
Seeing how many of those inputs are I32, your 1.6GB sounds like you might be encroaching in on the 2GB limit of an I32 with all of the handshaking characters. Can you break your transfers down into smaller blocks <1GB then reset (close/re-open) the DLL while continuing to run from previous spot?
Most likely you are onto something here too. VID and PID look like USB identifiers and they are in reality 16 bit unsigned integers. The DLL function may still declare them as int32_t and correctly cast them to the needed 16 bit unsigned integers internally, but it may just as much be that the person who set this Call Library Node up had little understanding about datatypes and how they relate to each other.
Hooly **bleep**, that code has a terrible memory leak!!!!!!
LONG __stdcall WriteUSBDevice(LONG *VID, LONG *PID, UCHAR *data,LONG size, LONG GLV,LONG staddr)
{
//create instance of CCyUSBDevice
CCyUSBDevice *USBDevice;
USBDevice = new CCyUSBDevice(NULL, CYUSBDRV_GUID, 1);
//OpenDevice
LONG num = 0;
int vID;
int pID;
int d = 0;
int devices = USBDevice->DeviceCount();
do{
USBDevice->Open(d);
vID = USBDevice->VendorID;
pID = USBDevice->ProductID;
d++;
} while ((d<devices) && (vID != (*VID)) && (pID != (*PID)));
if ((vID == (*VID)) && (pID == (*PID))){
num = 0;
}
else if (d >= devices){
num = 1;
}
else{
num = 3;
}
*VID = vID;
*PID = pID;
if (num != 0){ return num; }
int i;
UCHAR *array = new unsigned char[size];
array = data;
// for (i = 0; i < size; i++)
// {
// *(array++) = i;
// }
// size *= 4;
bool err;
err = false;
if (USBDevice->BulkOutEndPt){
err = USBDevice->BulkOutEndPt->XferData((unsigned char*) array, size);
}
data = array;
if (err = true)num =0;//OK
else num = 200;//NG
delete[] array;
delete USBDevice;
return num;
}
It first creates an array of the size indicated by the size parameter, the one you pass in with 1 decrement from the buffer passed into the LabVIEW VI. Then it immediately overwrites that allocated pointer with the pointer received from the caller. Then after the BulkOut call it assigns the array pointer back to the data pointer passed in, which is complete nonsense, and last but not least it tries to delete the array which is not the original array allocated in the beginning but the data pointer passed in from LabVIEW and which the delete operator has no business about messing with, nor is it likely able to as it is probably using a different allocator althogether than what LabVIEW is using.
Aside from that, creating a new device object for every single request and opening the communication channel to it to then deallocate it again is also terribly inefficient.
Wrapping this into a seperate executable to then call through network streams is simply building more crap on a wrecked piece of software.
