Linux RT CompactRIO segmentation fault

[MarkCG]

Hi all,

I am running a real-time LabVIEW application that calls into compiled .so file. I am getting occasional crashes of the entire system, and the error log shows a segfault

#Date: Mon, Jun 29, 2020 04:59:16 PM
#Desc: LabVIEW caught fatal signal
18.0.1 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x0x4
#RCS: unspecified
#OSName: Linux
#OSVers: 4.9.47-rt37-ni-6.1.0f0
#OSBuild: 264495
#AppName: lvrt
#Version: 18.0.1
#AppKind: AppLib
#AppModDate:

 

am I correct in blaming this on the code in the compiled .so file (which happens to be a ZeroMQ library) ? There really isn't a way for LabVIEW code to create a segfault AFAIK-- you don't have direct access to memory.

Also posted on the darkside but not expecting any response there.

[Tim_S]

Not familiar enough with Linux or ZeroMQ to give a specific answer, but thinking this through... Segmentation fault is the program trying to access memory it's not supposed to. Certainly been able to do that on Windows, so I don't see why can't do the same with Linux. Typically get that when working with drivers, which ZeroMQ would qualify as. Could be something like passing a pointer that is or becomes invalid, or trying to access memory that has been freed up.

[Rolf Kalbermatter]

On 6/30/2020 at 6:42 PM, MarkCG said:

Hi all,

I am running a real-time LabVIEW application that calls into compiled .so file. I am getting occasional crashes of the entire system, and the error log shows a segfault

am I correct in blaming this on the code in the compiled .so file (which happens to be a ZeroMQ library) ? There really isn't a way for LabVIEW code to create a segfault AFAIK-- you don't have direct access to memory.

Well if you are correct is of course not debatable at this time but there is definitely a chance for this. Don't disregard the VIs interfacing to the shared library though. A wrongly setup Call Library node is at least as likely if not more.

Obvously there seems to be something off where some code tries to access a value it believes to be a pointer but instead is simply an (integer) number (0x04). Try to locate the code crash more closely by first adding more logging around the function calls to the library to see where the offending call may be, and if that doesn't help by disabling code sections to see when it stops crashing and when it returns crashing.  My first thing would be to however review every single VI that calls this library and verify that the Call Library Node exactly matches the prototype of the respective functions and doesn't pass in unallocated or to short strings and array buffers.

LabVIEW certainly can cause segfaults but it is extremely rare that that happens nowadays in LabVIEW itself. But even LabVIEW developers are humans and have been known to bork up things in the past. 😀

Edited July 7, 2020 by Rolf Kalbermatter

[MarkCG]

Thank you Rolf and Tim. This crash has seemed to happen exactly one time but maybe with enough logging I'll figure it out. My other option is to just convince people get rid of ZMQ completely for this application and use UDP or TCP connection. The application is just sending data to one server anyways so ZMQ is not really adding much functionality anyways