LabView used inside a Plugin

[Nick.Muguira]

I have an application that loads a shared library at runtime. As part of the processing that the shared library performs, it creates a task using DAQmxBaseCreateTask. The situation I'm running into is this:

If the Application isn't linked against the LabVIEW libraries the process will lock up. If the Application is linked against the LabVIEW libraries the process will execute as expected except the process will crash on exit and a core file will be dumped.

LabVIEW caught fatal signal
7.0 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x541d0e

LabVIEW caught fatal signal
7.0 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x558768
Segmentation fault (core dumped)

I do ensure that both

DAQmxBaseStopTask(m_Handle);

DAQmxBaseClearTask(m_Handle);

are called on valid handles prior to unloading the library.

My questions are

1) Is there anyway to avoid the crash on exit?

2) Can I load the plugin without linking the loading application against the LabVIEW libraries?

I am using NI-DAQmx Base 1.5.0f2

Thanks

[RT4CY]

Hi Nick,

Thanks for posting on the NI Discussion forums!  I have a couple questions for you.

  -  What operating system are you using?
  -  What programming environment are you working in?
  -  What version of LabVIEW did you use?

You may want to consider upgrading your DAQmx Base driver to the current version.  There have been instances of this error message using Madrake and Fedore Core 2 flavors of Linux and LabVIEW 7.0.  The issue is a result of the fact that these flavors of Linux use a new directory indexing feature on their file systems.

If you are using Linux and an early version of LabVIEW you may want to check out some of these KnowledgeBase articles.

How do I Dynamically Load LabVIEW Built Shared Libraries from C on Linux?
Why Do I Get Segmentation Fault Errors When Installing LabVIEW 7.1 and Earlier on Linux?

[Nick.Muguira]

Hi,

Thanks for your response. I will definitely try the latest version of DAQmx Base driver to see if this mitigates the problem. To answer your questions

- Red Hat Enterprises Linux 4
- GCC (3.2 I think - whatever is standard with RH install)
- I believe LabView 7.0 (can verify this when I'm back in the office)

I will also consult the KB articles.

Thanks Again,
Nick

[Nick.Muguira]

Answers to questions in the previous post

Red Hat Enterprise Linux 4 - Kernel: 2.6.9-5.EL

GCC info:

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)

These are the libstdc++ packages that are installed:

libstdc++-devel-3.4.3-9.EL4
libstdc++-3.4.3-9.EL4
compat-libstdc++-296-2.96-132.7.2
compat-libstdc++-33-3.2.3-47.3

I was using this version 1.5 of the driver (http://joule.ni.com/nidu/cds/view/p/id/430/lang/en)

I am now testing with version 3.1 of the driver (http://joule.ni.com/nidu/cds/view/p/id/967/lang/en)

I've upgraded to the latest version of the Linux Driver (3.1 from Jan. 2008). This solves the problem where I need to link against the libraries in the application that loads my library. It also fixes a good number of crashes on exit, but I am still seeing quite a bit. I've verified that these crashes happen after the library is unloaded and immediately before the application exits.

A much dumbed down psuedo-code representation of my test app would be

Load the Library that uses LabView

Initialize the Library

Do some things using the Library

Unload the Library

Exit

I have a print statement immediately before my "return 0;" that I get, but still see a crash with the following printout:

LabVIEW caught fatal signal
8.2.1 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x89568b
Segmentation fault (core dumped)

Core files are useless as they have no stack in them, and I never see these crashes when I'm debugging inside of GDB. Any suggestions?

As an aside, this version of the driver requires a newer version of the firmware on the device (NI USB-6009). Is there a way to update this firmware from the command line? What are the risks of updating this firmware? Is there an easy way to downgrade the fw other than what's mentioned in these two KB's:

http://digital.ni.com/public.nsf/websearch/91CBCFE9E171C845862572CF0077D8F9?OpenDocument

http://digital.ni.com/public.nsf/allkb/1448A8AC665EE0EA8625703F004A4410?OpenDocument

Any solution would be preferably be non-windows as these devices are not accessible and are connected to a Linux workstation.

Thanks again for any help/suggestions you may be able to provide.

[RT4CY]

Hey Nick,

I would suggest updating the firmware on the USB.  You have two options, which can be found in the following bin.

usr/local/natinst/nidaqmxbase/bin

You can use the script dmxbUSBfirmware.sh which will match the firmware on the USB to the version of DAQmx Base you have installed on your machine.  To downgrade, simply uninstall your version of DAQmx Base, reinstall the previous version and run the script.

In the bin you will also find a LabVIEW VI called FWUpdate if you prefer a GUI interface.

Message Edited by RT4CY on 07-11-2008 10:14 AM

[Nick.Muguira]

I don't see dmxbUSBfirmware.sh with version 1.5 of the driver. Is it included with version 2.2? If so can I use that version with version 1.5 of the driver?

Thanks.

[Steve_B]

Hi Nick,

The dmxbUSBfirmware.sh file can be found in DAQmx Base 3.1 and this can be used to upgrade your firmware to the latest version. As far as downgrading you firmware and DAQmx Base you were correct with the two KnowledgeBase Article that you referenced above. The issue is that there was not a firmware loader in DAQmxBase until version 3.1. Due to this you will need to have a Windows machine and follow the appropriate procedures to use the firmware loader from DAQmx.

As far as the crashes, has this problem persisted from DAQmx Base 1.5 up to DAQmx Base 3.1 and what has changed as you upgraded the driver version? Also, what is the serial number of the device and is the firmware on it current?

[Nick.Muguira]

The serial number of the device that I am using for my testing is: 012D96B4. I've verified it on another device as well.

The crashes have persisted after updating to DAQmx Base 3.1 (and corresponding FW upgrade). If I run my executable under GDB I do not see a crash. Any core files generated from the crash do not have a stack trace. Any suggestions on how I can get to the bottom of this will be appreciated.

Thanks

[Steve_B]

Hi Nick,

I would appreciate it if you could generate an niSystemReport which will detail your current system configuration with all of your software versions. You can find this in /usr/local/bin/ and executing the command niSystemReport > ~/myReport. You need to be root in order to do this. You can include the system report file in an email to support@ni.com and putting "ATTN: Steve Banaska SR 1188655" in the subject.

I wanted to verify that you are on a 32 bit system and also to know what filesystem type you have. Also, was the pseudo-code representation you described C Code or LabVIEW code? There is a possible issue with your filesystem and LabVIEW 7.1 and earlier. Let me know the results of your ls -af command. I am referring to the issue described by the KnowledgeBase Article "Why Do I Get Segmentation Fault Errors When Installing LabVIEW 7.1 and Earlier on Linux?" that Rod referenced above.

[Nick.Muguira]

Hi Steve,

The processor is a P3 700 MHz processor.

The (poorly formatted by Outlook) output of ls –af is (truncated to meet character limits)

/root% ls -af

.                   .screenrc               libgr_types.so     .ICEauthority             .labviewrc

..                  .bash_history           2008127072133      .gnome2_private           .labviewrc.bak

/root%

Partial output of dumpe2fs

/root% dumpe2fs /

dumpe2fs 1.35 (28-Feb-2004)

dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /

Couldn't find valid filesystem superblock.

/root% dumpe2fs /dev/mapper/VolGroup00-LogVol00

dumpe2fs 1.35 (28-Feb-2004)

Filesystem features:      has_journal ext_attr resize_inode filetype needs_recovery sparse_super large_file

The pseudo code was C Code. Due to the large size of the project, sensitive nature of its development, and dependency on proprietary hardware it wouldn’t do much good to send you a copy of it. I can work out a mini sample of the problem if you would like. Let me know if this would assist you.

Thanks,
Nick