Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

openSuse11.2 LabVIEW caught fatal signal 10.0 - Received SIGSEGV Reason: invalid permissions for mapped object

Hi,

I get an error when trying to launch a jni wrapper for NIDAQmxBase for USB-6009 device:

 

With NIDAQmxBase3.4 I get:

 

LabVIEW caught fatal signal
10.0 - Received SIGSEGV
Reason: invalid permissions for mapped object
Attempt to reference address: 0x0xb7655890


 

 

I'm running NIDAQmxBase 3.4 now, but the same error with different Labview number occured with NIDAQmxBase 3.3, both on openSuse11.2.

 

With NIDAQmxBase 3.3, even the examples didn't work after that:

 

 

LabVIEW caught fatal signal
8.2.1 - Received SIGSEGV
Reason: invalid permissions for mapped object
Attempt to reference address: 0xb7648890

./acquireNScans                                                             

LabVIEW caught fatal signal
8.2.1 - Received SIGSEGV   
Reason: address not mapped to object
Attempt to reference address: 0x0   
Speicherzugriffsfehler           

 

 

 

That's why I switched back to 3.4 although createTask() takes very long.

 

This happens exactly when I call (from shared object, generated from cpp file)

 

 

DAQmxBaseCreateTask("",&taskHandle));

 

 

When I run the same method from a c++ project, whether as standalone application or as dynamic library, everything works fine.

The jni methods also work, when I don't call any methods from nidaqmxbase. As soon as a nidaqmxbase method is called I get these errors.

 

 

0 Kudos
Message 1 of 9
(5,862 Views)

I had to link the cpp part of the jni-project with -lnidaqmxbase -lniCPULib, otherwise  it would compile, but when running the java part it compains:

Unable to load libniCPULib.so from /usr/local/lib/LabVIEW-2010/libniCPULib.so

 As c++ project, the same program compiles and runs perfectly with -lnidaqmxbase, but also with -lniCPULib. I'm really confused. In short terms:

-program works as standalone and as shared object, when c++ only.

-works as jni, without nidaqmxbase method calls.

 

0 Kudos
Message 2 of 9
(5,856 Views)

HI MTer,

 

I'm not really able to help you. Have you seen these two links:

 

http://digital.ni.com/public.nsf/allkb/802A9D349090D3F5862565CC0076BCF9

http://forums.ni.com/t5/Measurement-Studio-for-VC/DAQmx-with-C-JNI-Java/m-p/856754?requireLogin=Fals...

 

As I understand you you can call the DAQmx functions compiled as a so from a C++ program, but not from a Java program?

 

Best Regards,

Andreas Stark
LabVIEW Lead @ Rocket Factory Augsburg
0 Kudos
Message 3 of 9
(5,827 Views)

Thx,

but the links only show the steps, I already have made.

 

>As I understand you you can call the DAQmx functions compiled as a so from a C++ program, but not from a Java program?

 

Except that I try to call DAQmxBase functions, that's right. To be more specific, the DAQmxBase functions are called from C++ files in both cases:

 

Method from CppWrapper.cpp, called from Java, produces the error:

 

JNIEXPORT jboolean JNICALL Java_JavaWrapper_createTask
(JNIEnv *env, jobject obj)
{
DAQmxBaseCreateTask("",&taskHandle);
return true;
}

 

Same method without DAQmxBaseCreateTask (..) from CppWrapper.cpp, called from Java, produces no error:

 

 

JNIEXPORT jboolean JNICALL Java_JavaWrapper_createTask
  (JNIEnv *env, jobject obj)
{
//      DAQmxBaseCreateTask("",&taskHandle);
      cout<<"I'm fine"<<endl;
      return true;
}

 

 

Same method from COnlyDyn.cpp without JNI stuff, called from another C++ program also works:

 

 

bool createTask()
{
      DAQmxBaseCreateTask("",&taskHandle);
      return true;
}

 

 

 

I attached the clean and build outputs and an error log, maybe someone can find a mistake there.

 

 

Download All
0 Kudos
Message 4 of 9
(5,807 Views)

To make confusion perfect:

Under Windows, the whole JNI-Wrapper works as expected, but only using Microsoft visual Compiler, but that's another story, I'll put that in another thread. The program itself doesn't seem to cause this error but the NIDAQmxBase driver for linux. Please tell me if I can help you debugging this.

0 Kudos
Message 5 of 9
(5,753 Views)

Did you play around with the linking order, maybe thats the trick. That's all I can help you.

 

Regards,

Andreas Stark
LabVIEW Lead @ Rocket Factory Augsburg
0 Kudos
Message 6 of 9
(5,735 Views)

MTer,

 

Did you ever figure this out? I'm running into the same message when calling a custom built .so from LabVIEW on Linux as well... Just curious if you ever found a solution.

0 Kudos
Message 7 of 9
(5,417 Views)

I have a similar issue when running 'gpibtst' ...

gpibtst gui crashes with :

 

Bit frustrating why? how? without any resouces from NI. It appears NI developers and Big Physics group clueless for days.

 

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

 

1. my OS is RHEL 6.3 (32 bit)

 

2. I increased the default stack  to 16K :

stack size              (kbytes, -s) 16384

3. I reduced the RAM count < 4096M  in grub by setting "mem=3072M"

 

4. I also set the SELinux to permissive mode:

 

sestatus:
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted


 

 

 

0 Kudos
Message 8 of 9
(5,009 Views)

I have a similar issue when running 'gpibtst' ...

 

gpibtst gui crashes with :

 

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

 

Here is my testing environment:

 

1. my OS is RHEL 6.3 (32 bit)

 

2. I increased the default stack  to 16K :

stack size              (kbytes, -s) 16384

 

3. I reduced the RAM count < 4096M  in grub by setting "mem=3072M"

 

4. I also set the SELinux to permissive mode:

 

sestatus:
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 24

 

Bit frustrating why? how? without any resources from NI. It appears NI developers and Big Physics group clueless for days.

 

0 Kudos
Message 9 of 9
(5,005 Views)