Calling "glutInit" cause LabVIEW crash

[brano.s]

Hi,

I am trying to use OpenGL in LabVIEW. I have compiled my source code into DLL which I called from LabVIEW with Call Library Function Node.  I have replaced the glutMainLoop of GLUT for glutMainLoopEvent of freeGLUT. This is because glutMainLoop never exits the OpenGL main loop and doesn't return the control to the calling function (LabView), glutMainLoopEvent does.

When program is run first time it goes OK; but when I run it for second time, LabView crashes and closes itself.

I found out that LabVIEW crashes when in DLL is called function:

glutInit( &argc, argv );

where

argc = 0;
char **argv = NULL;

Have you any suggestions how to fix this?

[rolfk]

From http://www.opengl.org/resources/libraries/glut/spec3/node10.html.

void glutInit(int *argcp, char **argv);

argcp

A pointer to the program's unmodified argc variable from main. Upon return, the value pointed to by argcp will be updated, because glutInitextracts any command line options intended for the GLUT library.

argv

The program's unmodified argv variable from main. Like argcp, the data for argv will be updated because glutInitextracts any command line options understood by the GLUT library.

How do you suppose the function will be able to update a NULL pointer?

[brano.s]

Thanks for your reply.

I changed it to:

int argc = 1;
char *argv = {"argv1"};

and I tried too:

int argc = 0;
char *argv = {"argv1"};

 but problem is still the same.

[rolfk]

On which OS is that?

And you are only calling glutInit() and nothing else?? If you do, then I'm pretty sure you should not be calling glutInit() as it is probably a function meant to be called by a command line application, so without it's own GUI. I'm pretty sure that you would need to call a different function from a GUI based application, as glutInit() may do various low level stuff that may not cooperate well with a GUI based application, and even less with how LabVIEW itself interacts with the windowing system on low level.

[brano.s]

It is on Win XP 32-bit.

After glutInit I am calling:

glutInitDisplayMode
glutInitWindiwSize
glutCreateWindow
glutDisplayFunc

glewInit ... 

 
What I do not understand why .VI w

What I do not understand why when program run first time it goes OK; but when I run it for second time, LabView crashes and closes itself.

Why first time it run OK and second not?

[rolfk]

This is a typical error when you call external code with invalid parameters. If you call the external code directly from LabVIEW it could be a misconfiguration of datatypes. But it is in most cases the lack of understanding about memory handling when calling C functions. If you call a C function you have to understand several basic rules about C programming. And the Call Library Node only supports standard C mechanismes as anything else is highly unportable on the ABI (Application Binary Interface) even between different versions of the same C++ compiler (not to talk about compilers from different sources).

One of those rules, and the one which is in 99% of the cases the culprit, is that ANY memory buffer (Array, String) passed to the callee, needs to be allocated in the caller (here your LabVIEW diagram). This means that when you call a function that expects a string to write 100 characters into, you better allocate a byte array of 101 elements in LabVIEW and pass that to the function. If you don't or even only forget to account for the additional zero byte string termination character, only passing a buffer with 100 or less elements in, the function will at some point overwrite some memory that is is not supposed to do. This CAN cause an immediate Invalid Memory Access Exception if that address happens to be outside of the currently allocated heap space for the process, but most likely this address simply is used for something else in the current process. So your function corrupts some data. This often doesn't cause an immediate crash but when you do something else, including starting your application again, your process stumbles over that corrupted memory location and causes some bad operation that often will crash.

This principle applies to both strings and arrays, since strings are in fact simply byte arrays with some specific semantic (typically zero character termination, but also other things such as character encoding).

I have seen errors caused by buffer overflows that did only crash when I tried to shutdown LabVIEW, as it had overwritten some memory location that were not vital for the operation of the program, but when LabVIEW was going through it's allocated resources to free them properly before quitting it got caught by pointers that had been invalidated by the buffer overflow error earlier.

[brano.s]

Thank you for your comprehensive answer.

If I get it right you suggest that when glutInit is trying to modifi argv accidentaly corrupt LabVIEW memory space, right?

I tryed to configure CLN so argc and argv are send to DLL from LabVIEW but it did not solve the problem. 

CLN configuration Parameters:

argc - Numeric, signet 32-bit Integer, passed by value

argv - String, Cstring Pointer

In DLL are parameters accepted as:

int argc

char *argv

[rolfk]

---

@brano.s wrote:

Thank you for your comprehensive answer.

If I get it right you suggest that when glutInit is trying to modifi argv accidentaly corrupt LabVIEW memory space, right?

I tryed to configure CLN so argc and argv are send to DLL from LabVIEW but it did not solve the problem. 

CLN configuration Parameters:

argc - Numeric, signet 32-bit Integer, passed by value

argv - String, Cstring Pointer

In DLL are parameters accepted as:

int argc

char *argv

---

No! That might be a problem too, but I was suggesting that one of the other functions you are calling, has a misconfigured or misallocated buffer, that causes that function to overwrite some memory it shouldn't, and causing LabVIEW later on, to crash.

What makes you think that glutInit() must be the culprit? The fact that a restart of the program crashes? Think again. Once anything in your program has corrupted memory, it will crash sooner or later. This can be as soon as you call the function in question or as late as several hours, days, weeks or months later, when your program executes a code path that tries to access data, that happens to be at the location your function has been overriding.

[brano.s]

It is probably glutInit because it is last function called in DLL before LabVIEW crashes.
It is always the same scenario, always call to glutInit causes crash.

[rolfk]

If it would be truely glutInit() it would most likely crash the first time already. What is more likely is that openGL itself gets messed up internally during some of the previous calls during the first run, likely becuase you happen to not pass in array buffers large enough for the function and when you call glutInit() again, it tries to clean up its internal objects, pointers and what else from the previous run and stumbles across the previously corrupted pointer.

Remember it's usually not the messanger that is the cause of the problem. Same with function crashes. They may be caused by memory corruption in some other, seemingly unrelated part of your program, sometimes just before the function call, but it can be just as well a call to a function that happened hours ago.