0
$\begingroup$

Rosanswers logo

Hi All

First of all, sorry, if this question has been asked already. I've indeed come across several questions that seem very related, but since the errors I'm getting are not the same I figured I'd just ask. This (question/57991/use-matlab-code-within-ros/) is very related but it doesn't completely ask the same question. This one (/question/33326/matlab-engine-and-ros-library-incompatible/) is also relevant, but the error reported is different from mine.

I'm using fuerte under Ubuntu 12.04 Precise and I would like to call some MATLAB functions that I have converted to MATLAB C++ Shared Libraries using MATLAB's mcc compiler (MATLAB R2012b in Ubuntu 12.04).

If I don't use ROS, but just a simple C++ example with CMake, everything works perfectly, and I'm able to call the MATLAB functions without problems.

However, when I try to do the same from a C++ ROS node, my node crashes with an strange error just after I try to execute the following line:

if (!mclInitializeApplication(NULL,0)) 

I get the error:

matlabLibServer: malloc.c:2451: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Aborted (core dumped)

The CMakeLists that I use is:

# Add MATLAB MCR include directories and lib directories
include_directories (${PROJECT_SOURCE_DIR}/lib /usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/extern/include/cpp /usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/extern/include)

# Add library directories for the libvigenere library and the MCR libraries
link_directories (${PROJECT_SOURCE_DIR}/lib /usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/runtime/glnxa64)

#uncomment if you have defined messages
rosbuild_genmsg()
#uncomment if you have defined services
rosbuild_gensrv()

#common commands for building c++ executables and libraries
#rosbuild_add_library(${PROJECT_NAME} src/example.cpp)
#target_link_libraries(${PROJECT_NAME} another_library)
#rosbuild_add_boost_directories()
#rosbuild_link_boost(${PROJECT_NAME} thread)
#rosbuild_add_executable(example examples/example.cpp)
#target_link_libraries(example ${PROJECT_NAME})

rosbuild_add_executable(matlabLibServer src/matlabLibServer.cpp)
rosbuild_add_executable(matlabLibClient src/matlabLibClient.cpp)


#Link with vigenere and with the MCR
target_link_libraries (matlabLibServer libvigenere.so mwmclmcrrt) 

Note however, that compiling and linking work perfectly.

Is there anyway to link to MATLAB Shared C++ libraries while using ROS at the same time? What I would like is to implement a ROS service that basically calls a MATLAB function with some arguments and then I get the output back (a couple of double arrays). This service would be called rarely but the MATLAB routine takes quite a while to complete (1-3 sec). I would like to avoid using other third party projects such as rosbridge or IPC-MATLAB bridge if possible..

Finally, if I was able to use MATLAB coder to completely generate C code for my current MATLAB functions instead of converting them to MATLAB MCR Shared Libraries, would my problem be solved? Has anybody had success with that?

Thanks a lot for your help.

###UPDATE:###

This gets interesting. So if I use the same source file, but I comment all the ROS parts (ros::init, etc), but leave the headers and use the same linking options (CMakeLists unmodified), then the program runs perfectly and is able to use the MATLAB shared library without problems.

In the same way, if instead I comment all the MATLAB parts in the code and use only the ROS parts (ros::init, etc) and leave the same headers and linking options (again same CMakeLists) then the program works fine.

It only crashes when I'm trying to call both (ROS and MATLAB Shared Library) parts at the same time.

The GDB trace stack that I get is not very informative:

GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<>...
Reading symbols from /home/efernan/Dropbox/MIT/MERS/Learning/WAMLearningDemo2013/ROS/matlabSimpleMCRLib/bin/matlabLibServer...done.
(gdb) run
Starting program: /home/efernan/Dropbox/MIT/MERS/Learning/WAMLearningDemo2013/ROS/matlabSimpleMCRLib/bin/matlabLibServer 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Initializing MATLAB's MCR
matlabLibServer: malloc.c:2451: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6d9e425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fbd780 (LWP 12211)):
#0  0x00007ffff6d9e425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6da1b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6de615d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff6de9664 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff6dec365 in calloc () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007ffff6da3b31 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x00007ffff6da3bf8 in __cxa_atexit () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x00007fffebfaa813 in ?? () from /usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/bin/glnxa64/libmwservices.so
#8  0x00007fffec0cfdc6 in ?? () from /usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/bin/glnxa64/libmwservices.so
#9  0x0000000000000000 in ?? ()
(gdb) 

The source for the ROS node that I'm trying to develop can be found in the following gist (github gist: /enriquefernandez/5254685)

ADDITIONAL INFO

Although I have MATLAB installed in my computer, I also installed MATLAB's MCR in my computer and modified the LD_LIBRARY_PATH env variable to point to several MCR directories as instructed by MATLAB. When I did that, cmake and other programs stopped working as they were complaining with the following error:

cmake: libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by cmake)

I discovered the reason for that is that now the folder usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/sys/os/glnxa64 was on my LD_LIBRARY_PATH and that there was a sym link libstdc++.so.6 pointing to libstdc++.so.6.0.13 in the same folder. I renamed libstdc++.so.6 to libstdc++.so.6_old and then cmake started working again. After this change everything has worked fine except for this problems with ROS and MATLAB together at the same time.

###BOOST LINKING PROBLEMS? ###

I've read in a different topic that this may be due to MATLAB R2012b and fuerte linking to different versions. Somebody suggested in (/question/12542/rosmatlab-simulink-communication/) that recompiling fuerte and making it link to the boost libraries used by MATLAB R2012b would solve these problems.

Anybody has an idea of how to do that? Obviously I'm not experienced at all in building C++ programs and having to link to complex libraries...

Thank you all for your help and sorry for the huge post. It's been really a huge disappointment seeing that I won't be able to use MATLAB and ROS this way...

Sorry for the bad style for the links. Unfortunately I'm not able to post links due to my karma level.


Originally posted by Enrique Fernandez on ROS Answers with karma: 26 on 2013-03-26

Post score: 1


Original comments

Comment by jbohren on 2013-03-26:
This is a memory corruption, can you update your question with a stack trace from GDB?

Comment by Enrique Fernandez on 2013-03-27:
Thanks a lot for your help jbohren. I've updated my question now.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Hi Javier

Unfortunately, I wasn't able to solve the problem and didn't even consider recompiling ROS. Because the way I was using my MATLAB code was pretty simple and I didn't have enough time to make things right, I ended up using the typical "hack" of making two programs: a standard C++ ROS node with no dependencies to the MATLAB code or MCR and another C++ program (not a ROS node) that linked to the MCR and the MATLAB shared library.

The C++ ROS node wrote the arguments needed for the MATLAB code as input files in a common folder and then called the C++ program that linked with the MCR. That same program then wrote the output to a common folder that was, at the end, read and parsed by the ROS node.

One final detail that I had to change is that the MCR installation was asking me to change my LD_LIBRARY_PATH, which was raising problems everywhere else in my system (OpenRAVE for example). Therefore, I wrote a simple bash script that just changed the LD_LIBRARY_PATH just before calling the program that linked to the MCR

echo Modifying LD_LIBRARY_PATH
old_lib_path=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/runtime/glnxa64:/usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/bin/glnxa64:/usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/sys/os/glnxa64:/usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/sys/java/jre/glnxa64/jre/lib/amd64/server:/usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/sys/java/jre/glnxa64/jre/lib/amd64:$LD_LIBRARY_PATH
export XAPPLRESDIR=/usr/local/MATLAB/MATLAB_Compiler_Runtime/v80/X11/app-defaults
echo LD_LIBRARY_PATH changed to $LD_LIBRARY_PATH

bin/PFTExpertNode
export LD_LIBRARY_PATH=$old_lib_path

As you can see, this is a really bad hack, but, because my application was simple enough, it was good enough for my needs.


Originally posted by Enrique Fernandez with karma: 26 on 2013-05-03

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by javiera on 2013-05-20:
Thanks! I managed by using Ubuntu 12.10 and Matlab 2013a, then there was no problem as the boost version is the same.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.