MATLAB library initialization failing due to (I suspect) multiple versions of boost thread library

We are trialling calling some MATLAB code for some key calculations from our C++ server. To do this we compiled a MATLAB C++ library as per documentation, and linked in to our server. All runs well until the eventual call to <LIBRARY>Initialize() (after the initial MatlabInitialize() call), where our server either crashes (most often) or hangs.

Our server is using boost version 1.46.1 which I see is much more recent than the one shipped with, and no doubt depended on by, MATLAB (1.36.1). If I link in the later boost version dynamically, it looks like the MATLAB libraries pick up the newer version, whereas linking statically causes MATLAB to use the older version. Either way our server still crashes and/or hangs at the same point.

To be absolutely sure this was a boost dependency problem I tried compiling a simple app with no dependency on boost that simply calls the two initialize functions, then the compiled calculation function. This runs fine.

We are using Linux/Ubuntu 11.04 64-bit MATLAB 2010a

Here is the gdb stack trace of the crash,

(gdb) where
#0  0x0000000000a4b506 in boost::thread::start_thread() ()
#1  0x00007fc4235870b0 in ?? ()
   from /usr/local/matlab2010a/bin/glnxa64/../../bin/glnxa64/libmwdservices.so
#2  0x00007fc4235849b6 in dsSetTimer(boost::function0<void> const&, boost::posix_time::time_duration, bool) ()
   from /usr/local/matlab2010a/bin/glnxa64/../../bin/glnxa64/libmwdservices.so
#3  0x00007fc423596960 in dsLockFile::dsLockFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::posix_time::time_duration, boost::shared_ptr<dsAbstractFS> const&) ()
   from /usr/local/matlab2010a/bin/glnxa64/../../bin/glnxa64/libmwdservices.so
#4  0x00007fc423592265 in dsDirectoryExclusiveLock::acquire(boost::posix_time::time_duration const&, bool) ()
   from /usr/local/matlab2010a/bin/glnxa64/../../bin/glnxa64/libmwdservices.so
#5  0x00007fc423592903 in dsDirectoryExclusiveLock::acquire(bool) ()
   from /usr/local/matlab2010a/bin/glnxa64/../../bin/glnxa64/libmwdservices.so
#6  0x00007fc42574b175 in ?? ()
   from /usr/local/matlab2010a/bin/glnxa64/libmwmclmcr.so
#7  0x00007fc4256bffd5 in ?? ()
   from /usr/local/matlab2010a/bin/glnxa64/libmwmclmcr.so
#8  0x00007fc4256c19be in ?? ()
   from /usr/local/matlab2010a/bin/glnxa64/libmwmclmcr.so
#9  0x00007fc42571755f in ?? ()
   from /usr/local/matlab2010a/bin/glnxa64/libmwmclmcr.so
---Type <return> to continue, or q <return> to quit---
#10 0x00007fc4257156fd in ?? ()
   from /usr/local/matlab2010a/bin/glnxa64/libmwmclmcr.so
#11 0x00007fc4256e3a13 in mclInitializeComponentInstanceEmbedded ()
   from /usr/local/matlab2010a/bin/glnxa64/libmwmclmcr.so
#12 0x00007fc433d40036 in mclInitializeComponentInstanceEmbedded_proxy ()
   from /usr/local/matlab2010a/runtime/glnxa64/libmwmclmcrrt.so
#13 0x00007fc4351193c3 in libligerchildInitializeWithHandlers ()
   from /home/jess/liger/thirdParty/lib/libligerchild.so
#14 0x00007fc435119403 in libligerchildInitialize ()

Any help or suggestions as to a potential fix would be most appreciated.

Thanks

Answer 1

[Jess]

After much hair pulling I sorted this out.

Briefly,

1. I built an "intermediate" wrapper shared library to call the MATLAB-generated shared library. This wrapper library had no dependency on boost.
2. I changed my exe to link STATICALLY to the later boost version I require.
3. I changed my cmake linker settings to not specify the -rdynamic option (which I believe tells the runtime loader to attempt to resolve symbol imports with symbols exported by the exe).
4. I changed my exe to runtime load the wrapper library (ie. dlopen).

All this amounts to an exe where my code is correctly linking to the later boost version, and the MATLAB libraries are correctly linking to the old version shipped with MATLAB.

I think the best solution however would be for MATLAB to link in boost statically and avoid this problem altogether. Either that or at least post some documentation to help with this kind of thing.

[DEEPIKA RAVI KRISHNA]

I have a .cpp file in which I'm creating the shared memory.Mex of this file was successful but when I debug the code there is an exception "MATLAB.exe has triggered a breakpoint" thrown from that line which has boost API for creating the shared memory. Should I use the above approach to resolve this?@Jess

Answer 2

[Peter Li]

One possible alternative solution in this situation is to just link your code against MATLAB's version of boost_thread. You may run into problems with this if you need a newer version; MATLAB seems to be on 1_40_0 for the time being. But I found this does work for my use (compiling Theron to use Actors model concurrency from MATLAB mex).

In order to do this, you have to download the proper headers for MATLAB's version from the boost web page; I couldn't find the headers anywhere in the MATLAB distribution. Once you have boost_1_40_0 downloaded, the headers are just under the "boost" directory in the main distribution folder after you unzip, so just add the boost_1_40_0 distribution folder to your -I and it should work. If you link against the wrong headers you will probably get segfaults.

As a final tip, I found it simpler conceptually to just add all the library files' complete paths (.../libtheron.a and .../libboost_thread.so.1.40) at the end of my mex statement, rather than trying to pull things in with -L and -l. It probably works either way, but putting the complete paths in gave me more confidence that the linker was doing exactly what I wanted.

(As a final final tip, if you are interested in Theron specifically there are some minor changes you have to make to the Theron makefile.)