CLFN labview crash

[tmf171]

I just upgraded to LabVIEW 2010 from 8.5.1 with hope that an application I have created will run faster. I immediately ran into a problem though with the Call Library Function Node (CLFN) that I cannot get around. I have checked all the knowledge bases and looked as hard as I could to find any solution to my problem. If I use the CLFN in 2010 the program will immediately crash (quietly killing LabVIEW, or locking it up completely) or return error 1097. This same VI loaded up in LabVIEW 8.5 or 8.6 runs perfectly fine. I have found this information: http://zone.ni.com/devzone/cda/tut/p/id/11869 . This led me to issue  221113 or CLFN with the wrong calling convention may siliently crash LabVIEW.

I figured that this knowledgebase would help me KnowledgeBase 59KB14WI

It doesn't thought because I am not permitted access to it, so all I have to do is use the right calling convention. I have tried all the calling conventions that I can think of, both of them, and the problem is still around. Does anyone have any ideas?

Thanks,

Tom

[charris]

Tom:

I have the same issue with the KB link, but that has to be a mistake. I'll track it down and see if I can get it reposted.

In the mean time, would you be willing to post a stripped-down VI with your dll in it that reproduces the error? If we could see the configuration information, it might help out a bit.

[tmf171]

Its basically just a VI with a DLL in it, nothing else. The inputs are for initialization and I run it. Labview crashes and closes. The DLL was made by a small company and I don't know how stable it is to begin with. I am just frustrated that it worked, but doesn't now. I have to no go backwards with all my code so that I can keep moving forward. If you can get more information on this it would be helpful. I could send the bare DLL and simple VI over if that would help you.

[LV_Pro]

I will mention that I am able to reach both links as of today. Basically all they say is that pre-2010 with maximum error detection set in the CIN, it would automatically detect an incorrect call method, correct it and send out an end, 2010 compiler "optimizations" won't do that. So it basic implies that the call conventions must match. Not sure what happens when you've tried all variations of calling convention. Having a similar problem, I think in 8.6.1, where I'm getting "silent" crashes (Dr.Watson pops up a window) that may be dll related.

[charris]

Tom:

It would be helpful, as I could at least attempt to replicate the issue here.

While the issue may or may not be related to the calling convention, I think I may have seen it relating to the input and output datatypes and how they're handled. That's the primary reason I'd like to see the actual dll and a calling VI. It doesn't need to be complicated, just something that will crash LabVIEW occasionally. I'll need to dig a little deeper and do some research, but the dll would be extremely helpful.

Also, I found that KB and got the permissions changed, so it should be accessible now.

Thanks!

[d_sdl]

I am having the same problem calling the MySQL libmysql.dll. Works great in LabVIEW 2009. Upgraded to LabVIEW 2010 and it doesn't work anymore. I have attached a sample VI. The documentation on the MySQL C Api is here . Any ideas on this would be appreciated.

[charris]

It looks like you're calling the init function using the C calling convention, but the second DLL call is using the std(winapi) convention. You may want to try changing the calling convention to C for the second call library function node.

Good luck!

[d_sdl]

If I switch both of the CLFN to use the stdcall (WINAPI) I get Error 1097. If I switch them to the "C" calling convention, it crashes LabVIEW. The exact same vi works perfect in LabVIEW 2009. No 1097 errors or crashing. If somebody has some insight on how to fix this I would really appreciate it. I am debating on whether or not to upgrade all of my systems to LabVIEW 2010 because of this bug.

[tmf171]

Eventually I had the DLL creator build a new DLL using LabVIEW 2010. It works in 2010 and I'm not seeing as many problems, but I still think there is something wrong with my own calling convention.

This did get kind of annoying. I feel like National Instruments really threw us a curveball with 2010.

[charris]

Judging by the return of the VI in 2010, it looks like there may be an issue with how the DLL itself is working within allocated memory. It doesn't crash LabVIEW on my machine (in either calling convention), but returns error 1097.

Granted, I only have the dll file, not what it's attempting to access, but it still appears to be an issue with the actual DLL execution, not the calling convention (I get the above error with either calling convention). This may or may not be related, but you may want to check this KB, namely the "overwriting LabVIEW Memory" section. Does the crash occur with other functions called in this particular DLL file, or just the "mysql_real_connect" function?

Running the VI in 2009, I receive a very similar error (also regardless of calling convention).

Again, this may be due to the fact that I don't have the actual database that the DLL is trying to access.

One other thing: on the first CLFN, the output terminal being used is "return type." Is that the desired output, or should "arg1" be wired?