DLL call fails when DLL uses a large array

[Jo-Jo]

I am calling a C++ dll in 32-bit LabVIEW on Windows 7. I kept getting error 1097, and eventually figured out it's because the dll is using two large arrays of 5 MB each. The arrays are being initialized in the constructor of an object, malloc is not being used, or anything. If I make the arrays much smaller, then everything works fine.

The problem isn't hard to work around now that I know what is causing it, but can anyone tell me why a dll using a lot of memory would be a problem? I don't feel like 10 MB is really a lot of memory to use on modern computers.

[a_clucker]

Hey Jo-Jo,

You seem to have knowledge of how the internals of the DLL works. Do you have the source code? Could you test running the C++ code - not in DLL form - with the same size of array? I ask because the error description:

points to an error within the code. If it fails when you call it in C++, you know it's the code.

If it doesn't fail as normal C++ code, try calling the DLL from a different environment. This will help you determine if it's the DLL itself (perhaps the way it's called) or a problem with calling the DLL in LabVIEW.

[Jo-Jo]

Thanks for the reply.

I wrote the dll myself, so I definitely have knowledge of the internals. I tried using the class all by itself in a test project in Visual Studio before I wrapped in the dll, and it worked fine. I thought maybe there is some limit that I'm not aware of either in LabVIEW or in Windows that is preventing this from working, but Googling didn't seem to bring anything to light.

[a_clucker · Accepted solution]

Ok, can you test calling the DLL in a Visual Studios test harness?

Also, in case you haven't seen other 'DLL error 1097' type threads, here are a few. The cause of 1097 in your case might be illuminated by a wealth of past troubleshooting:

Error 1097 calling dll

Error Code 1097 Coming in DLL Calling

error 1097 after calling dll function which allocates memory inside

Error 1097 when passing array from C++ DLL to LabView (looks very relevant, albeit long)

I know it's a lot of reading, but there's a very good chance the magic hint is in one of those threads already. Let's stand on the shoulders of their work.

[rolfk · Accepted solution]

There is absolutely no limit in LabVIEW about how much memory can be allocated other than the physical limit given by the architecture (in total 2  GB (3 GB with special boot switch) for 32 bit applications and about 16GB for current day CPUs when using 64 bit applications).

error 1097 is definitely an error that is caused when your DLL somehow throws an exception somewhere, explicitedly through a real throw statement that your wrapper code to interface your C++ code to the LabVIEW standard C Call Library Node interface doesn't catch, or implicitedly by trying to access invalid memory or things like a division by zero floating point exception.

The fact that smaller allocations seem to work could be just a red hering. It may limit your code to access incorrect memory anyhow but within the constraints of what Windows considers valid memory for the LabVIEW process, so the virtual memory protection doesn't cause an exception, but something in memory might get corrupted anyhow. Or something in your code changes indirectly so that you indeed don't do an invalid access!

[Jo-Jo]

I read through most of the 1097 error code posts already when I was troubleshooting this, but, as is often the case, my problem was just a little different.

I fixed the problem by just passing in the buffers from LabVIEW, which is the way it should be done anyway. I was just using static buffers in the dll for initial debug because I thought it would be harder to screw up.

Unfortunately, I don't have time to find out what was really going wrong, but maybe one more thread about error 1097 will be helpful to someone.

Thanks for the help.

[rolfk]

Well, static memory is a little different than dynamic memory. This is allocated at load time of the according object module (DLL or EXE) into the process data segment and may have certain limits. Most likely you tried something in your code that doesn't work with data segment memory properly.

All diagram memory and just about anything else in LabVIEW that you as LabVIEW programmer ever could get in contact with is fully dynamically allocated on the heap and the only limit there is that it can not exceed the available heap space for a process. If you had done a malloc() in your code at the first execution of the code (or inside the DLL_PROCESS_ATTACH case) and a free() in the DLL_PROCESS_DEATTACH you would get the same effect as with memory passed into the DLL from LabVIEW.