LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Call Library Node Error 1097

Solved!
Go to solution

I have a dll that appears to work fine except for the error 1097's it throws for certain functions.  The DLL enables get/set command on a piece of hardware.  The 'set' commands throw this error.  Despite the error the CLN appears to correctly 'set' the function, so I'm not sure what is going wrong.  I don't see any evidence of corrupted memory as a result of the error.

 

-It isn't the calling convention

-The CLN is correctly configured to match the header near as I can tell. 

     -(however I'll not one thing I found confusing. If the CLN is set such that the parameter that should be a pointer sized value (according to the header) is set to a 32 bit value, the CLN complete equally well. This is surprising)

 

A snippet and the relevant header follow. I did not write or compile the library code, I received the compiled dll from the vendor.  (I cannot confirm therefore that the dll was compiled form the source below, though the vendor says that it is)

CLN_snippet_err1097.png

 

Header:

#define EXPORT extern "C" _declspec(dllexport)

#include <net-snmp/net-snmp-config.h>
#define NET_SNMP_SNMPV3_H                   // we don't need SNMPV3 (one include file is missing)
#include <net-snmp/net-snmp-includes.h>

typedef void* HSNMP;   // SNMP handle (like FILE)

const char* readCommunity = "public";       ///< community name for read operations
const char* writeCommunity = "guru";        ///< community name for write operation

// DLL functions
void __stdcall syslog(int priority,const char* format,...);
int __stdcall SnmpInit(void);
void __stdcall SnmpCleanup(void);
HSNMP __stdcall SnmpOpen(const char* ipAddress);
void __stdcall SnmpClose(HSNMP m_sessp);

//Utility Functions
double __stdcall snmpSetDouble(HSNMP m_sessp, const char *name, double value);
double __stdcall snmpGetDouble(HSNMP m_sessp, const char *name);
int __stdcall snmpSetInt(HSNMP m_sessp, const char *name, int value);
int __stdcall snmpGetInt(HSNMP m_sessp, const char *name);

char* __stdcall snmpGetString(HSNMP m_sessp, const char *name);

Thanks for any thoughts people may have.

 

I'll also mention, that this error didn't occur in the 32bit version I was previously provided and was using.  This problem seems unique to the 64 bit dll.

0 Kudos
Message 1 of 13
(4,836 Views)

Just to make sure.

When you use the 32 bit .dll you use LabVIEW 32 bit and when you use the 64 bit .dll you use LabVIEW 64 bit...

Benoit

0 Kudos
Message 2 of 13
(4,801 Views)

Could you do a save for previous and save it as 2016 or earlier? From the pic alone it doesn't seem like there would be something wrong.

One small correction, when you say that the manufacturer claims that the DLL was compiled using the shown source, this isn't actually the source for those functions, just the header containing the function definition.

 

There is a chance that the DLL is actually doing something bad and causing an exception either in the called function itself or in one of the functions it calls. If this exception is not caught in the DLL itself, LabVIEW will catch it and translate it to the 1097 error. So definitely something to discuss with the vendor of this DLL.

 

Also there is no chance to have the wrong calling convention in 64-bit LabVIEW as it only supports the default calling convention which is __fastcall.

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 13
(4,791 Views)

Hi Rolf,

 

Thanks for your reply.  

I only have LV 2017 in the x64 variant. I have to download/install 2016 x64 and test it there I will let you know what happens.  Vendor says ("They don't have labview x64 and so can't test their own dll"(1) to confirm my result)

 

 

Knew that's just the declaration Smiley Happy  I didn't think someone would be willing to wade through the source, but from the header might catch an error i made configuring the CLN.

 

Interesting about __fastcall, I was unaware of that.

 

source from function, obviously this only serve to catch errors occurring here.  maybe something gnarly with those casts(?)

double __stdcall snmpSetDouble(HSNMP m_sessp, const char *name, double value) {

  size_t length = MAX_OID_LEN;
  oid parameter [MAX_OID_LEN];

  if(!get_node(name,parameter,&length)) {
		syslog(LOG_ERR,"OID %s not found", name); return false;} 
  struct snmp_pdu* pdu = snmp_pdu_create(SNMP_MSG_SET);    // prepare set-request pdu
  pdu->community = (u_char*)strdup(writeCommunity);
  pdu->community_len = strlen(writeCommunity);

  // for(each SET request to one crate) {
  float v = (float) value;
  snmp_pdu_add_variable(pdu,parameter,length,ASN_OPAQUE_FLOAT,(u_char*)&v,sizeof(v));
  // } // endfor
  
  value =v;
  struct snmp_pdu* response;
	int status = snmp_sess_synch_response(m_sessp,pdu,&response);

  /*
  * Process the response.
  */
  if (status == STAT_SUCCESS && response->errstat == SNMP_ERR_NOERROR) {
    /*
    * SUCCESS: Print the result variables
    */
    struct variable_list *vars;
    
    // debug print
    //for(vars = response->variables; vars; vars = vars->next_variable)
    //  print_variable(vars->name, vars->name_length, vars);

    /* manipuate the information ourselves */
    for(vars = response->variables; vars; vars = vars->next_variable) {
			if (vars->type == ASN_OPAQUE_FLOAT) {				    // 0x78
        value = *vars->val.floatVal;
      }
			else if (vars->type == ASN_OPAQUE_DOUBLE) {			// 0x79
        value = *vars->val.doubleVal;
      }
			else if(vars->type == ASN_INTEGER) {				      // 0x02
				value = (double)*vars->val.integer;
      }
	}
  } else {
    /*
    * FAILURE: print what went wrong!
    */

    if (status == STAT_SUCCESS)
      fprintf(stderr, "Error in packet\nReason: %s\n",
      snmp_errstring(response->errstat));
    else
      snmp_sess_perror("snmpget",snmp_sess_session(m_sessp));
    return 0;
  }
  snmp_free_pdu(response);
  return value;
}

 

0 Kudos
Message 4 of 13
(4,781 Views)

Save for Previous is an option in all LabVIEW versions since around 5.0. And since 8.2 you can save back in all versions back to the 8.0 format. But it's usually fine to save it two versions earlier than the current version (which would be 2018) to make it possible for most active people on the forum to read it.

 

I don't see an obvious error in the C source code right away, though it is kind of involved and so not easy to analyze for that kind of trouble.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 13
(4,779 Views)

Thanks for taking the time to look at the code.

 

I knew about back-saving, but how does that help in this case?  You can only call DLL functions successfully if the hardware is present right?

 

I did test it in LV 2016 x64 per your suggestion and I get the same error 1097. 2016 snippet, vi, and dll attached if interested.  

 2016_snippet.png

Download All
0 Kudos
Message 6 of 13
(4,774 Views)

I did not expect it to work in LabVIEW 2016 at all. The reason that I asked you to backsafe it is that I currently only have LabVIEW 2016 installed on my work machine, and checking Call Library Nodes from a picture is very much not helpful. To much information in the Call Library Node configuration is simply not visible in the picture.

 

And yes I can of course not test it on my machine without the correct hardware. But I will take a look at the VIs.

 

Next step if it was my problem, would be to compile a debug version of the DLL in Visual C and then single step through the DLL function to see if it somewhere causes an exception. It may not because of the debug compilation rather than the release compilation but it is at least one possible check.

Rolf Kalbermatter
My Blog
Message 7 of 13
(4,771 Views)
Solution
Accepted by topic author AdamZeroK

So I checked the VI and compared it to the header file declaration and I can't find a reason why the code should cause a 1097 error. Now LabVIEW doesn't create such errors randomly so something is going wrong inside that function.

 

And here you really have to start debugging on source code level in the C code. I'm pretty certain that the error gets visible pretty soon then. It could be an exception or it could be a buffer overflow somehow.

 

You can also try to increase the debugging level in the Call Library Node to maximum. That might give extra pointers as to the problem. Ignoring the 1097 is NEVER a solution if you don't know EXACTLY why it is happening. Something happened that could have pretty grave consequences at some point after you start to modify seemingly unrelated parts in your application that change the actual memory layout of the structures in memory in such a way that a now critical data pointer is at the location the DLL is corrupting and that could make itself only apparent after you installed the application in your end system. So never ever ignore errrors that you do not absolutely fully understand!

Rolf Kalbermatter
My Blog
Message 8 of 13
(4,754 Views)

Hi Rolf,

 

Thanks for you continued support.

 

I agree with your assessment.  I did increase the debugging level and unfortunately it didn't provide any additional insights.  I agree debugging the DLL is a good next step.  Unfortunately rebuilding their DLL from the source I have will be pretty time consuming. Hopefully I'll be able to do this before this project needs to be complete

0 Kudos
Message 9 of 13
(4,750 Views)

Do you only have the source code or also the Visual C project files? Because with the project files it should be as little as changing the compile target to Debug Mode and rebuilding.

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 13
(4,743 Views)