LabVIEW caught fatal signal 21.0 - Received SIGSEGV

[AlexElb]

Thank you for your fast reply and specific details. Seems like on my machine, the page looks different... 🤔

Anyhow, I've installed RHEL 8.6 and LabVIEW 2020 SP1 is starting now.

edit: RHEL provided me some OS updates, after installing them, LV won't start any more. So I guess it was not related to RHEL 8.6 vs 8.8, but the updates screwed dependencies up. (I had also installed the updates on RHEL 8.8 before installing LabVIEW.)

[AlexElb]

It was an issue with SELinux, if the Alert Browser is installed, it mentions a problem.

After executing these commands, LabVIEW can start normally:

# ausearch -c 'labview' --raw | audit2allow -M my-labview
# semodule -X 300 -i my-labview.pp

SELinux Alert Browser log:

Spoiler

SELinux is preventing /usr/local/natinst/LabVIEW-2020-64/labviewprofull from using the 'execheap' accesses on a process.

***** Plugin allow_execheap (53.1 confidence) suggests ********************

If you do not think /usr/local/natinst/LabVIEW-2020-64/labviewprofull should need to map heap memory that is both writable and executable.
Then you need to report a bug. This is a potentially dangerous access.
Do
contact your security administrator and report this issue.

***** Plugin catchall_boolean (42.6 confidence) suggests ******************

If you want to allow selinuxuser to execheap
Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean.

Do
setsebool -P selinuxuser_execheap 1

***** Plugin catchall (5.76 confidence) suggests **************************

If you believe that labviewprofull should be allowed execheap access on processes labeled unconfined_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'labview' --raw | audit2allow -M my-labview
# semodule -X 300 -i my-labview.pp

Additional Information:
Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
023
Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
023
Target Objects Unknown [ process ]
Source labview
Source Path /usr/local/natinst/LabVIEW-2020-64/labviewprofull
Port <Unknown>
Host (removed)
Source RPM Packages labview-2020-profull-exe-20.5.0.49152-0+f0.x86_64
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-3.14.3-117.el8_8.2.noarch
Local Policy RPM selinux-policy-targeted-3.14.3-117.el8_8.2.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name (removed)
Platform Linux (removed) 4.18.0-477.21.1.el8_8.x86_64 #1
SMP Thu Jul 20 08:38:27 EDT 2023 x86_64 x86_64
Alert Count 2
First Seen 2023-08-21 09:37:04 CEST
Last Seen 2023-08-21 09:37:04 CEST
Local ID 111b7f09-c0f2-4e3b-b10b-729f8fb60120

Raw Audit Messages
type=AVC msg=audit(1692603424.669:274): avc: denied { execheap } for pid=8987 comm="labview" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0

type=SYSCALL msg=audit(1692603424.669:274): arch=x86_64 syscall=mprotect success=no exit=EACCES a0=6ad3000 a1=5000 a2=7 a3=6ad38c0 items=0 ppid=7048 pid=8987 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=tty2 ses=2 comm=labview exe=/usr/local/natinst/LabVIEW-2020-64/labviewprofull subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Hash: labview,unconfined_t,unconfined_t,process,execheap

[rolfk]

---

@eejit wrote:

I did come across this link, but it dates from 2004, surely this would have been fixed by now?
Fedora is the bleeding edge version of Redhat 
But I'm running Btrfs and not ext4 so 'tunefs' is not going to work

http://web.archive.org/web/20190528203555/http://digital.ni.com/public.nsf/allkb/A2D53C8E0D88380B862...

---

The tunefs fix mentioned in that link has been addressed in the LabVIEW 7.1.1 bugfix release. It's definitely not that one problem.

But SIGSEGV is pretty much the same as the Windows General Protection error. And there are effectively zillion possible reasons that it crashes, including libc version compatibility and many more things.

For my LabVIEW 2014 on Fedora 36 installation the SELinux fix above did help. Seems that LabVIEW needs read and writeable heap mapping for its built in compilation and executing the code directly from heap memory.