CLFN labview crash

[d_sdl]

Caleb

Thanks for the reply. Yes the "return type" output terminal is the one that I want to use. Basically what I am doing is running the code at How to connect to MySql Database without using Database Connectivity Toolkit LV 2009 in the NI Developer Community. I don't use the Database connectivity toolkit because I don't like running my database inserts through an ODBC connection.

That link to the KnowledgeBase article helped, So between each CLFN I am passing a pointer to a MYSQL* handle. I am using a signed Int32 datatype for this, maybe I am using the wrong datatype? Is there an example somwhere that shows how to correctly pass a pointer between CLFNs?

I agree that it is an issue with the DLL execution but I don't understand why this works (no 1097 errors) in LabVIEW 2009 and doesn't work (1097 errors in the "mysql_real_connect" call) in LabVIEW 2010. To further clarify, the attached example returns the MySQL server version as a string and it correctly returns it in LabVIEW 2009 and 2010 but in LabVIEW 2010 the "mysql_real_connect" CLFN returns a 1097 error. So in LabVIEW 2010 if I don't connect the error wires between the "mysql_real_connect" CLFN and the "mysql_get_server_info" CLFN then I get the 1097 error after the "mysql_real_connect" CLFN executes but then the "mysql_get_server_info" still executes correctly and gets the server version.

The attached example doesn't connect to a specific database, it just queries the MySQL server info. If you have the MySQL server running on your machine you should be able to run it in LabVIEW 2009 without getting the 1517 error. For the LabVIEW 2009 machine I am using 32 bit LabVIEW 2009 with the f3 patch and Windows XP 32bit with 2 gigs of ram and dual processors. For the LabVIEW 2010 machine I am using 32 bit LabVIEW 2010 and Windows 7 64 bit with 4 gigs of ram and a core 2 extreme processor.

[BillView]

I am having very similar problems with CLFN for a C library built by a co worker.  Labview 2010 will crash when using a specific function.  I've verified that the calling is correct, and also tried specifying the .dll name only instead of the full filepath.  I still crash in 2010, while 2009 has no problems. 

Did changing the calling method fix your crash?

If the dll is located in a folder defined under your Environment Variables -> Path, did specifying the dll filename only instead of the filepath help?

My issues does not appear to be anything listed under the known bugs, I'm curious if your symptoms are the same.

[Rob_Calhoun]

I had the same issue but it seems to be calling-convention related.

In LabView 2009 I was calling a DLL using C calling conventions. It worked fine. After upgrading to LabView 2010 I got error 1097 or a silent LabView crash, depending on my luck. Changing the calling conventions fixed it, but led to the question, How did this ever work?!? So thanks to all who posted in this thread for pointing out CAR 22113 / KB 59KB14WI as an explanation for what is going on...I was really baffled how the same DLL could work with two different calling conventions!

Sorry it doesn't fix your issue, d_sdl. Here are a couple of other things to look at:

• Could there be an issue with a 64-bit mysql library?
• You asked about data types for pointers; best practice since LV 2009 is to use the "pointer-sized integer" type for pointers; that will automatically use the right size when you move between 32- and 64-bit LabView. But it doesn't matter for what you are doing; pointers are a U32 under 32-bit LabView, and the computer can't tell the difference between signed and unsigned. I32s should work.
• We sometimes had crashes when passing LabView clusters to C routines because the C compiler had added extra bytes at the end of the struct as padding. There's no way to know you need to pass the extra bytes from the LabView side without testing sizeof() with the compiler used to compile the DLL. (This isn't relevant with the simple types in your example, but maybe you have code like that somewhere else.)
• I'm not familiar with the mysql api, but generally you should not be passing 0x00 to indicate a null string (as you do for *db and *unix_socket). You should pass an empty LabView string to CLFN, with string format set to "C String Pointer". LabView will add a null on the end before passing it to the DLL and likewise will strip off the trailing 0x00 when the string is returned to LabView. Try just passing "".
• unsigned long client_flag is probably a U32, not a U64. 
• Although not relevant to any of the posts in this thread, I wanted to mention the invaluable "MoveBlock" CIN function in LabVIEW itself, which lets you copy some data out of the DLL and return it to LabView. If you need to get data from a DLL and all you have is a pointer, this function is your friend! It uses C calling conventions (at least that's what I've always used!)

-Rob

[Rob_Calhoun]

Oh, the other thing to mention is that the LabView compiler in 2010 is totally new. They are now generating LLVM instructions from the LabView code and allowing LLVM to product the actual platform-specific object code. So there might be something that was technically incorrect before that did not cause a crash because the object code was not as tightly optimized as it is now.

[rolfk]

---

@tmf171 wrote:

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

---

Your problem sounds like a bug in the DLL or the parameter configuration in the CLNF. The calling convention can't really be an option unless the function has no parameters, otherwise it would not have worked in your earlier LabVIEW version either. The calling convention in 32 bit LabVIEW is about who cleans up the stack after the function call, C means that the caller does that, stdcall means that the callee itself does it. If they don't match and the function has any parameters, the stack obviously gets badly messed up and will cause a bad crash or exception immediately.

What most likely happens is that you pass in an buffer parameter that is smaller than what the DLL expects. Inside the DLL call the function tries to write to that buffere causing an access violation. And the reason that didn't happen before is sheer unluck. Yes unluck since the DLL call did most likely actually corrupt data anyhow but in an area of the memory that was not immediately fatal and maybe not at all for in your specific situation. So you had been running a time bomb all the time and not knowing about it. this time bomb theoretically could have destroyed data in your application, creating invalid results without noticing you and that is why I say you were unlucky that it did not crash.

[rolfk]

---

@d_sdl wrote:

The prototype for mysql_real_connect is:

MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned long client_flag)

unsigned long under 32 bit LabVIEW is an uInt32 NOT an uInt64. Not sure that is the problem but it is definitely wrong.

Also what is the NULL string? Is it set to show binary format? If so I'm still wondering why you would do that. Unless you require a double NULL terminated string LabVIEW will turn an empty string into an empty NULL terminated C string when passing it to the function.

And the function documentation says that this parameter should be NULL when not used. That is not a string containing NULLs nor an empty NULL terminated string but a NULL pointer instead. And you create a NULL pointer in LabVIEW by configuring the CLN parameter to be an integer and passing it a 0 value.

Last but not least unless you are in LabVIEw previous to 8.6 you really should use the pointer sized integer CLN datatype for all pointer types (MYSQL*, and those NULL string parameters) to avoid hassles when you ever should upgrade to the 64 bit version of LabVIEW (and of course the 64 bit version of the mysql client library).

[Rob_Calhoun]

Rolf wrote:

 > The calling convention can't really be an option unless the function has no parameters, otherwise it would not have worked in your earlier LabVIEW version either.

Well, that's the funny thing with what NI revealed in KB 59KB14WI. Apparently in LabView 8.6 and 2009 (but not earlier), LabView would silently (!) fix bad calling conventions. Now that I read the appropriate header file for DLL I am using, it very clearly states that it should be called using the __stdcall calling convention. But the DLL in question absolutely worked under LV 2009 using C calling conventions, presumably because LabView was silently fixing it with every call.

Note to NI engineering: if the compiler notices we're doing something idiotic, PLEASE TELL US!

[rolfk]

---

@Rob Calhoun wrote:

@Rolf wrote:

 > The calling convention can't really be an option unless the function has no parameters, otherwise it would not have worked in your earlier LabVIEW version either.

Well, that's the funny thing with what NI revealed in KB 59KB14WI. Apparently in LabView 8.6 and 2009 (but not earlier), LabView would silently (!) fix bad calling conventions. Now that I read the appropriate header file for DLL I am using, it very clearly states that it should be called using the __stdcall calling convention. But the DLL in question absolutely worked under LV 2009 using C calling conventions, presumably because LabView was silently fixing it with every call.

Note to NI engineering: if the compiler notices we're doing something idiotic, PLEASE TELL US!

---

@I can see what you might be going at. The compiler can't really guess what calling convention the called function has without very involved disassembly analysis and I'm 200% sure they do not do that. What they most likely do is using some heuristic that can work but doesn't have to. It is common under Windows to have stdcall functions have decorated names. That means that the compiler adds in fact a @# to the end of the funtion name where the # is the number of bytes passed as parameter on the stack. This is however no requirement at all but only a convention. You can disable that with a single compiler option at compile time.

@Labview always has had heuristics to match a plain function name with a decorated name when there was only a single match available. Seems they also added the fix to overwrite the calling convention in case where they detected the @# name decoration to explicitedly use stdcall, independant of the actually selected calling convention. This is a convinience but not a safe heuristic. And I agree that the compiler should have generated a warning about this somewhere.

[jeffyy]

I have the same problem with my CLFN. It works great in labview 2009 but I'm now trying to rebuild everything in 2010. I have created a debug DLL and ran this version through visual studio. What I found was that even though the function within the DLL was executing correctly, I still got a 1097 error. I then, tried the winapi calling convention. This didn't produce the error. The problem is; I'm using the "C" calling convention in my DLL. I need 2010 because I'm using Veristand 2010.

JY

[jeffyy]

It seems that LV 2010 is a bit more stringent with respect to calling a DLL. I followed this example and was able to get my DLL to work properly, which begs the question; how did it work in the first place.

JY