nitargetcfg.so crash on sbRIO9607

[KHartley]

We've been debugging our application LV 2016 with a call to create and tear down our specific classes. We seem to be able to exacerbate an error in nitargetcfg.so despite our main application not calling into it.

We have some webservices that open a (one) session handle to system configuration to allow the user change the ip address without using internet explorer/silver light. I have one call that is requested when we load a webpages that retrieves the current ip settings for the target. It probably gets called 5 times tops in the hour it takes to crash the target. The two most recent crashes point to 
0xB4846000 - /usr/local/natinst/lib/libnitargetcfg.so.1 + 28000
0xB4881BD4 - _ZN2ni9targetcfg7network30GetDeviceSupportedModesByIndexEmPm + 54

0xB4B463AC - /usr/local/natinst/lib/libnitargetcfg.so.1 + 283AC
0xB4B85868 - _ZN2ni9targetcfg7network32GetDeviceTCPIPRequestModeByIndexEmPm + D8

I'm attaching the lvfailure logs below. 

Is this a known car? Any workarounds?

I'm trying to disable the call to see if the crashing goes away or if its the system configuration in general is causing the issue.

[KHartley]

I do not believe the error is with calling IPMode explicitly but maybe more broadly. I guess I'm cutting out any references to any ip information to see if I can contain this. 

[DigDoug]

Hi Kyle,

Looking at the error log I noticed the line: 

appweb: Error: Cannot open a socket on *:808002/12/2018 16:31:41

One common cause for this error is that the port is already in use when the application tries to call it. Is there another application that might be reserving the port? Or perhaps two parts of your application are trying to access the same port at the same time?

Best,

[KHartley]

Aaron,

I found what you are looking at but I believe the relation is flipped the cannot open socket occurs after the Real Time Process restarted.

I believe the cannot open socket is probably attributed to either the webserver being down (disabled rt app checked, or deploying a new version of the webservice) as I'm debugging. However when the RT process restarts there is a cannot open socket almost immediately after. So I don't believe this is the culprit. *update* Simply restarting the target creates a entry about "Cannot open a socket on *:8080"

02/12/2018	15:42:04	appweb: Error: Cannot open a socket on *:8080
02/12/2018	16:31:41	0	1633	41	LabVIEW Real-Time process restarted	
02/12/2018	16:31:56	appweb: Error: Cannot open a socket on *:8080
02/12/2018	16:50:34	appweb: Error: Cannot open a socket on *:8080
02/12/2018	16:53:25	0	1633	41	LabVIEW Real-Time process restarted	
02/12/2018	16:53:41	appweb: Error: Cannot open a socket on *:8080
02/12/2018	17:33:36	appweb: Error: Cannot open a socket on *:8080

 I did rework some code that would tries to open a connection with SysConfig and our application and it could have bled a sysconfig connection if our app connection failed. This should be in the order of ~10 orphaned connections but eventually it is successful because we can communicate our application. Anyway. I'm now cleaning up after myself.

I ran a test last night that failed after ~45 minutes with MAX left open. (45 minutes is typically when I've seen a failure by)

With the same software by simply restarting the target from max and closing MAX has run ~120 minutes this morning. 

Restart same software I'm verifying right now if it does crash again after ~45 minutes with MAX open for the test.

[DigDoug]

Hi Kyle,

It makes sense that those errors would be thrown after the Real Time Process restarts, good catch. Did cleaning up the code that opens a connection to SysConfig yield positive results?

[KHartley]

No it seems to sporadically happen still. Testing kind of led me to having MAX open while the computer goes to sleep/hibernate is causing this crash but I can't get a 100% reproduction. 

Can you have someone in system software and look at the crash? Can they tell me more or is there any easy copy of a debug library I can throw down there to get more info? It feels partially like a connection timing out after not in use. Because when it does happen it reoccurs around 45 minutes everytime. Speeding up our rebuild test vi did show the issue occurring any more quickly.

If I'm abusing the library its one thing for SysConfig not to work but crashing the RT will be a show stopper for our integration if we can't find a way to isolate it. 

[DigDoug]

Hi Kyle,

I recommend opening a service request for this question by calling 866-275-6964 or at ni.com/support.

That will be the best way to get this crash in front of the right eyes. If this is a bug we certainly want to address it, and I believe the most effective way will be through a service request. 

Have a great weekend,

[KHartley]

For anyone else curious this definitely involves the Web-Based Configuration page. Selecting the network settings page without logging in will cause the library to crash after 45 minutes.

Keeping MAX open at the same time appears to make the crash occur more frequently.

[Wang_Liming]

have resolve the problem?