This question is getting super specific, but I would appreciate if anybody has seen something like this with other hardware?

I am having the problem where Adlink's GPIO example code is working as expected when running on the SBC without ROS. However, if a node is built using Adlink's shared library upon execution, a core-dump/memory trace occurs. This occurs without any manipulation of GPIO state simply attempting to execute a node build with the Adlink shared object.

The suspect test only contains ros::init() and is liked to the Adlink provided .so file as well as library header files. Simply linking in the .so seems to cause the node to fail. If either ros::init() or the .so are absent, the node will execute.

I am currently talking to one of their sales engineers, but I was curious if anybody has seen anything like this with other SBC's onboard GPIO?

Edit: ldd of libsemaeapi.so (as requested):

/lib64/ld-linux-x86-64.so.2 (0x00007fdba3cd7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdba19e5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdba2ae7000)
libEApi_1.so.3 => /usr/local/SEMA/lib/libEApi_1.so.3 (0x00007fdba3110000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdba1daf000)
liblog4cpp.so.5 => /usr/local/SEMA/lib/liblog4cpp.so.5 (0x00007fdba285a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdba1fc5000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fdba15af000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdba2ceb000)
libsema.so.3 => /usr/local/SEMA/lib/libsema.so.3 (0x00007fdba2ef3000)
libsema_hwlinux.so.1.7 => /usr/local/SEMA/lib/libsema_hwlinux.so.1.7 (0x00007fdba2650000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdba22ce000)
linux-vdso.so.1 =>  (0x00007ffc2dd82000)

edit retag close merge delete

1

The suspect test only contains ros::init() and is liked to the Adlink provided .so file

What other libraries is the Adlink .so linked to (ie: what is the output of ldd /path/to/adlink.so)?

And as always with crashes of C++ nodes: build with RelWithDebInfo or plain Debug and run the node in gdb to get a stacktrace and post that here.

( 2019-04-10 12:27:09 -0500 )edit

I will work on getting gbd output shortly

( 2019-04-10 14:09:27 -0500 )edit

Did you get to the bottom of this?

( 2019-05-03 04:48:58 -0500 )edit

I'm currently running into the exact same issue as described. ros::init() throws an std::length_error(), even though I've verified the inputs to the function are correct. hardyn were you ever able to resolve this issue?

( 2019-07-08 12:34:00 -0500 )edit

I still suspect a corruption somewhere caused by symbol clashes or something similar.

( 2019-07-08 15:27:55 -0500 )edit

I will have the senior developer that figured it out reply to this thread, as he is the one that solved it. What it seems to be is the SEMA driver contains a version of Boost that conflicts with that used by ROS Kinetic. A symbol clash as @gvdhoorn suggests. It was solved by making an alteration to the roslog? node as the SEMA driver is supplied as binary.