linking dealii (compiled with MPI) to MATLAB engine results in segmentation fault

[Mathieu]

Hello everyone,

within my dealii program, I want to do some tasks using matlab functions, i.e.,

I want to call matlab functions/scripts from within my dealii (.cpp) program.

To this end, I modified my top-level CMakeLists.txt,

included the headers

#include "MatlabDataArray.hpp" 

#include "MatlabEngine.hpp"

#include <iostream>

in my program, and tested the interface by calling the function

void callFevalsqrt() 

{ 

// Call MATLAB sqrt function on array 

using namespace matlab::engine; 

// Start MATLAB engine synchronously 

//GIVES SEGFAULT         

std::unique_ptr<MATLABEngine> matlabPtr = startMATLAB(); 

}

as recommended by matlab here.

However, the call startMATLAB() results in a segmentation fault (core dumped) 

without any additional stack trace. 

I compiled dealii with MPI and the cxx compiler found by cmake is from openmpi-4.1.3. 

I narrowed my program down and installed dealii without any dependencies

to use the default cxx compiler on my system (gcc 11.3.0). 

Long story short, calling callFevalsqrt() runs without any errors. 

From this, I include that dealii compiled with MPI and the MATLAB engine can not be combined (because matlab does not support compilers from MPI ?)

Has someone experience with that and can provide a workaround?

Thanks for help!

Best regards,

Math

[Wolfgang Bangerth]

On 6/21/23 11:42, Mathieu wrote:
>
> I compiled dealii with MPI and the cxx compiler found by cmake is from
> openmpi-4.1.3.
> I narrowed my program down and installed dealii without any dependencies
> to use the default cxx compiler on my system (gcc 11.3.0).
> Long story short, calling callFevalsqrt() runs without any errors.
> From this, I include that dealii compiled with MPI and the MATLAB engine can
> not be combined (because matlab does not support compilers from MPI ?)
>
> Has someone experience with that and can provide a workaround?

Mathieu:
I don't know whether anyone has run into exactly this problem. What happens if
you write a small program that does not use deal.II at all, but uses the uses
the cmake scripts of one of the deal.II tutorial programs? That is, you take
one of the deal.II tutorials, and replace the entire code of that program by
just a minimal thing that calls Matlab but does not call anything in deal.II
nor uses any of the deal.II #include files?

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Mathieu]

"I don't know whether anyone has run into exactly this problem. What happens if
you write a small program that does not use deal.II at all, but uses the uses
the cmake scripts of one of the deal.II tutorial programs? That is, you take
one of the deal.II tutorials, and replace the entire code of that program by
just a minimal thing that calls Matlab but does not call anything in deal.II
nor uses any of the deal.II #include files?"

Good point to narrow down the problem.

I modified step-1 so that the main function only calls matlab via callFevalsqrt().

This works fine, even if I use the mpi compiler mentioned in my original post. 

However, if I just add a second line in the main function,

dealii::Triangulation<2> triangulation,

I run again into the segfault. 

Including deal.II headers seems to be not the problem, using dealii members/functions seems to a problem.

Clearly, the compiler shipped with openmpi seems not to be the real problem,

although I do not see the above issue with the default compiler on my system. 

Attached is the minimal program that I created along with the CMakeLists.txt. 

In case you have matlab installed and can reproduce my problem, you only have to replace 

<matlabroot> in line 8

by what matlabroot() returns. 

Any idea why adding any dealii members/functions causes a segfault in startMatlab() ?

May I have to pass some compiler flags to cmake, given that it works with the default compiler?

Thanks,

Math

[Wolfgang Bangerth]

On 6/22/23 03:13, Mathieu wrote:
>
> Any idea why adding any dealii members/functions causes a segfault in
> startMatlab() ?
> May I have to pass some compiler flags to cmake, given that it works with the
> default compiler?

I have no experience using Matlab, much less linking to it. I think you need
to run the program in a debugger to see what is happening.

[Matthias Maier]

On Thu, Jun 22, 2023, at 04:13 CDT, Mathieu <mathi...@gmail.com> wrote:

> Good point to narrow down the problem.
> I modified step-1 so that the main function only calls matlab via
> callFevalsqrt().
> This works fine, even if I use the mpi compiler mentioned in my original
> post.
> However, if I just add a second line in the main function,
> dealii::Triangulation<2> triangulation,
> I run again into the segfault.

What happens when you include this statement in yourr main function is
that your main.cc compilation unit now contains a symbol to the deal.II
library. The linker will then keep libdeal_ii.so as a shared object
dependency. If you do not actually use any symbol from the deal.II
library itself then the linker might drop the shared object altogether
and the final result is as if you never linked to deal.II in the first
place. You can verify this by running "ldd" on the executable:

$ ldd executable
libdeal_II.so.9999 => /usr/lib64/libdeal_II.so

Best,
Matthias

[Mathieu]

Thanks Matthias for clarification. 

But as I said, I do not have this problem using the default compiler on my system. 

Since I have no experience with a debugger, I let valgrind run on the program:

valgrind --tool=memcheck --leak-check=full --track-origins=yes ./step-1

(see the attachment for the output). 

From the memcheck, I can not deduce anything that would bring me closer to the bottom.

Do you have any suggestions based on the memcheck?

I could imagine there is a mismatch between some deal.II dependencies (TBB ?) and the 

corresponding versions shipped with matlab.

Best,

Math

[Matthias Maier]

The most likely issue will be a "symbol clash" either due to ABI
incompatible versions of the same external shared library linked into
the executable, or due to the matlab shared library you are linking
against containing these.

Can you send us the output of $ ldd executable (for a faulty one)?

Furthermore, have you tried running the startup in a debugger such as
gdb? If possible, the stacktrace for the segfault will be very
illuminating:

$ gdb executable
> run
> bt

Best,
Matthias

[Mathieu]

See ldd.txt for the output of 

$ ldd ./step-1

and gdb.txt for the output of

$ gdb ./step-1

Does this help?

[Matthias Maier]

In the debugger after you ran with the command »r« could you please try
to generate a back trace with »bt«?

(gdb) r
...
(gdb) bt
...

Best,
Matthias

[Mathieu]

Attached is the backtrace. 

Maybe there is an issue with the libmwmvm.so library. 

This library is not explicitly listed under the linked dependencies (ldd ./step-1), 

but I do not know if this is the problem or not.

Maybe you have a better understanding of the backtrace.

Best,

Math