Segmentation Fault when linking with NIDAQmx Base 2.0 (in Linux)

[maht]

Hello all!

I'm using NIDAQmx Base 2.0 in Linux to access a USB-6009, but when I compile that simple program

#include <NIDAQmxBase.h>

int main(int argc, char **args)
{
  return 0;
}

it outputs gives me a segmentation fault. I have tried, and the problem is when the program has to exit (for example by calling the exit() function).

I attach a .zip file with a little code and a Makefile, to make easy to reproduce the error.

Maybe it's a configuration error of my enviroment, but I pretty sure that all is ok. I'm using Mandriva 2006.0 Official and the DAQ examples works great.

Waiting for an answer, thanks in advance

    Miguel Ángel

[Shawn B.]

Well, it looks like your code/Makefile attachment failed, or perhaps you forgot.  Without seeing your Makefile, I can only make random guesses about what is going wrong.  Here is my first guess:

Why Does my Application Segmentation Fault When Using the pthread Library?

Shawn B.
National Instruments

[maht]

Sorry, I forgot to "attach the attachment" ... sorry ... 🙂

In the zip file is the Makefile.

Doing 'ldd' on the library generated it appears  the pthread library so  maybe you are right with your guess.

I'll check it tomorrow (I cant right now), reading your link about pthread before done anything else.

Thanks!

[maht]

Hello again! I tried using -pthread flag, and even -ldl flag but it doesn't work, with the same segmentation fault as before. The command line I'm using is:

gcc -ldl -pthread -Wall -I/usr/local/natinst/nidaqmxbase/include  -lnidaqmxbase withNIDAQmxBase.c -o withNIDAQmxBase

and the program is the same as before:

#include <NIDAQmxBase.h>

int main(int argc, char **args)
{
  return 0;
}

It is only happening to me? Could be a problem only of version 2.0 of NIDAQmx Base?

Best regards!

Miguel Ángel

[klt]

You're absolutely not the only one; I get the exact same problem !

[JHn]

When debuging this kind of errors, it is always a good idea to look in the syslog (sometimes you can get an indication of the problem there). Open a separate terminal and run (as root):

    # tail -f /var/log/messages

and whatch what happens when you run your program.

Another suggestion is to run your program under strace. strace will print all syscalls that your program does and you will probably find clues to your problem there as well. Using strace is as simple as this:

    $ strace withNIDAQmxBase

Good luck!

[maht]

Well, I'm surprised that this thread is active again after one year 😉

I think I have narrowed the location of the problem. It seems to be in the TimeInSecs function of the library liblvrtdark.so.8.0. The following are the tests I did that lead me to think that.

Just for fun, as JHn suggested, I've tried to see into /var/log/messages while running the examples I provided but nothing happens. The strace command is more useful. Running "strace ./withNIDAQmxBase" gives a lot of messages. The last lines are:

access("/usr/local/lib/liblvrtdark.so.8.0", R_OK) = 0
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local/lib/liblvrtdark.so.8.0", {st_mode=S_IFLNK|0777, st_size=32, ...}) = 0
readlink("/usr/local/lib/liblvrtdark.so.8.0", "LabVIEW-8.0/liblvrtdark.so.8.0.1", 4096) = 32
lstat64("/usr/local/lib/LabVIEW-8.0", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local/lib/LabVIEW-8.0/liblvrtdark.so.8.0.1", {st_mode=S_IFREG|0644, st_size=7050640, ...}) = 0
open("/usr/local/lib/LabVIEW-8.0/liblvrtdark.so.8.0.1", O_RDONLY) = 5
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340f\5"..., 512) = 512
fstat64(5, {st_mode=S_IFREG|0644, st_size=7050640, ...}) = 0
close(5)                                = 0
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 😎 = 0
write(4, "\240\306h\267\0\0\0\0\340\352\332\267\320P\203\267\320"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 😎 = 0
rt_sigsuspend([] <unfinished ...>
--- SIGRTMIN (Unknown signal 32) @ 0 (0) ---
<... rt_sigsuspend resumed> )           = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [RTMIN])
gettimeofday({1183025545, 797204}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 3089 detached

So the process seems to load the liblvrtdark.so.8.0 library and just before it die it call the gettimeofday system call. Well, not so bad, but the call to gettimeofday seems to work properly (the numbers that appears in {...,...} are indeed the actual seconds and microseconds of the timeval struct ).

So, lets try running gdb:

[root@host nidaqmxbase-exit-bug]# gdb withNIDAQmxBase
GNU gdb 6.3-5mdk (Mandriva Linux release 2006.0)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /tmp/nidaqmxbase-exit-bug/withNIDAQmxBase
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 3018)]
[New Thread 32769 (LWP 3021)]
[New Thread 16386 (LWP 3022)]
[Thread 16386 (LWP 3022) exited]
[New Thread 32771 (LWP 3023)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3018)]
0xb781f6be in TimeInSecs () from /usr/local/lib/liblvrtdark.so.8.0
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[root@host nidaqmxbase-exit-bug]#

So the segmentation fault occurs in a function called TimeInSecs int the liblvrtdark.so.8.0. To check that a function of this name exists we can use the nm command:

[root@host nidaqmxbase-exit-bug]# nm --debug-syms --dynamic /usr/local/lib/liblvrtdark.so.8.0 | grep TimeInSecs
000b6630 T TimeInSecs
[root@host nidaqmxbase-exit-bug]#

So the strange segmentation fault must be related with some bug in the "pointer logic" of the TimeInSecs.

Anyone from NI that could see the TimeInSecs source code and give us some light at this ... or fix the bug 😉

Bye!

[tivoter123]

Is there a solution/workaround to this problem? I have tried the -pthread and -ldl flags to no avail.

[AdamKemp]

Could you show an actual backtrace at the point of the crash? I just tested that function in 8.0 and 8.5 using the dark runtime engine, and it worked fine for me (I was not using daqmxbase). I also see no problem with the code.

[tivoter123]

While I have not done super extensive testing on this issue, it appears as though (in my case anyway -- using a USB-6051 for digital out only), I will only get a segmentation fault when I build an application against the DAQmxBase libraries, but do not write to any digital line. If I write to at least one line before the program exits, I do not get the segmentation fault.

For example, running something like

int main(void)
{
    return 0;
}

and building it with -lnidaqmxbase flag will result in a segmentation fault (which seems to be the same problem as the OP).


Message Edited by tivoter123 on 12-03-2007 07:54 PM