Errors using a dll to attach to shared memory

[Nishchey]

I have been given he task to read all data from the existing dll’s in labVIEW and broadcast the data to the clients.
Currently, I am having trouble with one of the dll’s written in C. When passed a memory key name and key number, if no error was detected, my labVIEW program attaches to the shared memory where the data is located. When the labVIEW program (main loop) is terminated I release the memory location. I don’t have a problem when I put in the correct key name and number, however, sometimes when I enter an erroneous key (for testing purposes) labVIEW gives me an Application error and terminates my program. As I said, this does not happen every time. The dll function returns an error c
ode “2” if it cannot attach to the shared memory for the given key name and number. I know that this dll works in other programs ( C ) when called, and it does not give an application error when a non-existent key is passed to the dll. I have attached a few of errors from what I get from the labVIEW program when I enter the erroneous key.

To summarize, the dll (testmanLib.dll) returns an error when an erroneous (non-existent) key name and key number is passed and the calling program should not give an Application error under these circumstances.

I have stripped the labVIEW code which just has the attached to shared memory function dll . Of course whatever key you put in when you run this program will be erroneous and that is the issue I would like to address. LabVIEW should not give me an Application error or any other error as shown in the attached file.

I have attached the labVIEW program testOpenShm.vi and the testmanLib.dll for your review.

Is there a
function in labVIEW that clears the memory?
Please let me know if you need any more information.

Regards,

Nish

E-mail: Nishchey.chhabra@ps.ge.com
Phone: 864-254-4666

[mikeporter]

Try initiaizing the error string connection. Instead of writing a null string to it, I connected a string of 128 nulls. I have run the VI (the LV6 version) for more than 300 loops and no crash and memory consumption appears to be stable.

Without this modification, it crashed on the first iteration.

Mike...

[cktears]

I checked your VI and found it might have a couple of errors.
1. You may have to use stdcall (WINAPI) to replace C in calling convention.
2. Wrong use of CSTR. I used U8 Array to replace your CSTR but still got error message, however this time Labview 7 didn't exist after the error.
3. Labview doesn't allow memory allocation to interfere with its own memory allocating stategy. Such problem might exist in your DLL. I wish I could give you more help, if what your DLL does was disclosed.

[mikeporter]

The issue is that you have to essentially "pre-allocate" the space for the error string that the DLL returns. I did this by passing in a string of 128 characters. This should work as long as a return error isn't longer that 128 characters.

After making this modification I ran the VI for over 300 iterations (that's more than 600 DLL calls) with no problems.

Mike...

[Nishchey]

Thanks for the suggestions.
I tried changing the dll calling convention to WINAPI however that did not work (I got an exception error).
Also, I got the same results as you did (labVIEW terminated) when I used U8 array to replace CSTR.
One thing that still puzzles me is that this code (attach to shared memory) works fine when I enter a valid memory key and memory handle number. I can release the shared memory and reattach to the same-shared memory a number of times without any errors. The moment I enter an invalid (non-existent) memory key to the same dll, I get an application error that pops-up sometimes right away or after I run the VI several times with the same erroneous key. A few times I just ran the VI once with entering a non-existent key and I did
not get an application error right away, but when I went to edit the VI I received an application error. It seems that labVIEW is still trying to attach to a non-existent shared memory even when the VI is not running (just a guess).
I will try to get a hold of the section of the C code that attaches to the shared memory
I appreciate your help.

[Nishchey]

By 128 nulls do you mean that you attached a string constant and entered \0 128 times?
I appreciate your help.
Thanks

[mikeporter]

yes, the easiest way to do this is use the initialize array function to create a 128-element array of U8s and then convert that array into a string using the byte array to string function.

Mike...