Thread Subject:

C++ Mex file crashes matlab on 64bit linux, but not 32 bit windows, but program runs fine outside Matlab

Hello,

I have written a mex gateway function to a C++ class. If I compile this mex function on 32Bit windows using R2008a I have no problems. If I compile and run on Matlab R2011a running 64bit Scientific Linux (a version of Red Hat Enterprize Linux) matlab exits with a segfault when the mexfunction is called, although it appears to run about halfway through the program. The C++ class can be compiled and run (with a main function) outside of Matlab on both platforms with no errors. I am using Microsoft Visual C++ Express Edition on the windows machine, and gcc 4.4.5 on the Linux machine.

Can anyone suggest what the cause of this might be and how I can I fix it?

I am having a hard time debugging on Linux as I do not have access to a graphical debugger for use with matlab and am unfamiliar with gdb. This is compounded by the fact that the program compiles and runs fine when compiled as a standalone program.

A zip file containing the code and data files necessary to reproduce the problem can be downloaded from http://www.see.ed.ac.uk/~s0237326/downloads/mexcrash.zip. This zip file contains the .m and .cpp source code, and a text file for testing (Temp.fem). The file fmehsersetup.m shows the commands I am using to compile. The file Test_mexfmesher.m runs the mexfunction with an appropriate input for testing. The mex gateway function is mexfmesher.cpp, it calls the fmesher class which is made up of the files in the fmesher directory.

Below is a backtrace from the segfault:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff721be36 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwservices.so
(gdb) backtrace
#0 0x00007ffff721be36 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwservices.so
#1 0x00000034daa914f2 in std::basic_ostream<char, std::char_traits<char> >::flush() () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libstdc++.so.6
#2 0x00007ffff72302b0 in ioFlush () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwservices.so
#3 0x00007ffff61303f5 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#4 0x00007ffff61330ec in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#5 0x00007ffff6130c7a in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#6 0x00007ffff6131741 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#7 0x00007ffff618a7d9 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#8 0x00007ffff686d7ef in Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**) () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_dispatcher.so
#9 0x00007ffff61731f0 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#10 0x00007ffff6114975 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#11 0x00007ffff612e96e in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#12 0x00007ffff61330ec in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#13 0x00007ffff6130c7a in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#14 0x00007ffff6131741 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#15 0x00007ffff618a7d9 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#16 0x00007ffff686d7ef in Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**) () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_dispatcher.so
#17 0x00007ffff61669b2 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#18 0x00007ffff6128e13 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#19 0x00007ffff6127eb7 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#20 0x00007ffff6128397 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#21 0x00007ffff6d378fe in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwbridge.so
#22 0x00007ffff6d384ae in mnParser () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwbridge.so
#23 0x00007ffff6ae0d39 in mcrInstance::mnParser_on_interpreter_thread() () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#24 0x00007ffff6ac3db2 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#25 0x00007ffff6ac3ec0 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#26 0x00007fffee8badb6 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libmwuix.so
#27 0x00007fffee8c413d in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libmwuix.so
#28 0x00007fffef3110bd in sysq::during_F<boost::weak_ptr<sysq::ws_ppeHook>, boost::shared_ptr<sysq::ws_ppeHook> > std::for_each<__gnu_cxx::__normal_iterator<boost::weak_ptr<sysq::ws_ppeHook>*, std::vector<boost::weak_ptr<sysq::ws_ppeHook>, std::allocator<boost::weak_ptr<sysq::ws_ppeHook> > > >, sysq::during_F<boost::weak_ptr<sysq::ws_ppeHook>, boost::shared_ptr<sysq::ws_ppeHook> > >(__gnu_cxx::__normal_iterator<boost::weak_ptr<sysq::ws_ppeHook>*, std::vector<boost::weak_ptr<sysq::ws_ppeHook>, std::allocator<boost::weak_ptr<sysq::ws_ppeHook> > > >, __gnu_cxx::__normal_iterator<boost::weak_ptr<sysq::ws_ppeHook>*, std::vector<boost::weak_ptr<sysq::ws_ppeHook>, std::allocator<boost::weak_ptr<sysq::ws_ppeHook> > > >, sysq::during_F<boost::weak_ptr<sysq::ws_ppeHook>, boost::shared_ptr<sysq::ws_ppeHook> >) ()
   from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libuij.so
#29 0x00007fffef312989 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libuij.so
#30 0x00007fffef30f4ae in svWS_ProcessPendingEvents(int, int, bool) () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libuij.so
#31 0x00007ffff6ac21c7 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#32 0x00007ffff6ac260a in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#33 0x00007ffff6ac2d6f in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#34 0x00000034d7a077e1 in start_thread () from /lib64/libpthread.so.0
#35 0x00000034d72e573d in clone () from /lib64/libc.so.6
(gdb) quit

Thanks!

On 24 Nov, 11:01, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> Hello,
>
> I have written a mex gateway function to a C++ class. If I compile this mex function on 32Bit windows using R2008a I have no problems. If I compile and run on Matlab R2011a running 64bit Scientific Linux (a version of Red Hat Enterprize Linux) matlab exits with a segfault when the mexfunction is called, although it appears to run about halfway through the program. The C++ class can be compiled and run (with a main function) outside of Matlab on both platforms with no errors. I am using Microsoft Visual C++ Express Edition on the windows machine, and gcc 4.4.5 on the Linux machine.
>
> Can anyone suggest what the cause of this might be and how I can I fix it?

Segmentation faults are usually caused by rogue pointers.
These kinds of errors are notoriously hard to track down.

In order to track it down yourself, you need to learn how
to program both C and C++. (Those are two intimatelt related
but different languages).

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message <77265aa1-d8f8-4e28-8f58-589798cf5f68@j10g2000vbe.googlegroups.com>...
> On 24 Nov, 11:01, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> > Hello,
> >
> > I have written a mex gateway function to a C++ class. If I compile this mex function on 32Bit windows using R2008a I have no problems. If I compile and run on Matlab R2011a running 64bit Scientific Linux (a version of Red Hat Enterprize Linux) matlab exits with a segfault when the mexfunction is called, although it appears to run about halfway through the program. The C++ class can be compiled and run (with a main function) outside of Matlab on both platforms with no errors. I am using Microsoft Visual C++ Express Edition on the windows machine, and gcc 4.4.5 on the Linux machine.
> >
> > Can anyone suggest what the cause of this might be and how I can I fix it?
>
> Segmentation faults are usually caused by rogue pointers.
> These kinds of errors are notoriously hard to track down.
>
> In order to track it down yourself, you need to learn how
> to program both C and C++. (Those are two intimatelt related
> but different languages).
>
> Rune

Yes, but is it not curious that the class can be compiled and run outside Matlab with no errors using the same compiler on the same system, but yet it crashes matlab?

I have some familiarity with C and C++ but am not familiar with gdb. On my 64Bit linux system, this is the only tool available for debugging this mex file.

I believe the problem could be related to calls to the 'free' function. Are there any known problems with this?

Thanks,
Richard

On 24 Nov, 11:46, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <77265aa1-d8f8-4e28-8f58-589798cf5...@j10g2000vbe.googlegroups.com>...
> > On 24 Nov, 11:01, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> > > Hello,
>
> > > I have written a mex gateway function to a C++ class. If I compile this mex function on 32Bit windows using R2008a I have no problems. If I compile and run on Matlab R2011a running 64bit Scientific Linux (a version of Red Hat Enterprize Linux) matlab exits with a segfault when the mexfunction is called, although it appears to run about halfway through the program. The C++ class can be compiled and run (with a main function) outside of Matlab on both platforms with no errors. I am using Microsoft Visual C++ Express Edition on the windows machine, and gcc 4.4.5 on the Linux machine.
>
> > > Can anyone suggest what the cause of this might be and how I can I fix it?
>
> > Segmentation faults are usually caused by rogue pointers.
> > These kinds of errors are notoriously hard to track down.
>
> > In order to track it down yourself, you need to learn how
> > to program both C and C++. (Those are two intimatelt related
> > but different languages).
>
> > Rune
>
> Yes, but is it not curious that the class can be compiled and run outside Matlab with no errors using the same compiler on the same system, but yet it crashes matlab?

No. That's why these kinds of errors are so hard to track down.

> I have some familiarity with C and C++ but am not familiar with gdb. On my 64Bit linux system, this is the only tool available for debugging this mex file.

Then you need to learn how to use gdb.

Or you could debug the code on one of the systems where
you have familiar debuggers. The coding error will be
the same on all platforms.

> I believe the problem could be related to calls to the 'free' function. Are there any known problems with this?

The obvious problem would be to free the same pointer twice.
Which is one form of a rogue pointer. (There are several.)

Rune

"Richard Crozier" wrote in message <jal79g$88d$1@newscl01ah.mathworks.com>...
> Rune Allnor <allnor@tele.ntnu.no> wrote in message <77265aa1-d8f8-4e28-8f58-589798cf5f68@j10g2000vbe.googlegroups.com>...
> > On 24 Nov, 11:01, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> > > Hello,
> > >
> > > I have written a mex gateway function to a C++ class. If I compile this mex function on 32Bit windows using R2008a I have no problems. If I compile and run on Matlab R2011a running 64bit Scientific Linux (a version of Red Hat Enterprize Linux) matlab exits with a segfault when the mexfunction is called, although it appears to run about halfway through the program. The C++ class can be compiled and run (with a main function) outside of Matlab on both platforms with no errors. I am using Microsoft Visual C++ Express Edition on the windows machine, and gcc 4.4.5 on the Linux machine.
> > >
> > > Can anyone suggest what the cause of this might be and how I can I fix it?
> >
> > Segmentation faults are usually caused by rogue pointers.
> > These kinds of errors are notoriously hard to track down.
> >
> > In order to track it down yourself, you need to learn how
> > to program both C and C++. (Those are two intimatelt related
> > but different languages).
> >
> > Rune
>
> Yes, but is it not curious that the class can be compiled and run outside Matlab with no errors using the same compiler on the same system, but yet it crashes matlab?
>
> I have some familiarity with C and C++ but am not familiar with gdb. On my 64Bit linux system, this is the only tool available for debugging this mex file.
>
> I believe the problem could be related to calls to the 'free' function. Are there any known problems with this?
>
> Thanks,
> Richard

Further to this, my question has effectively been answered by Jan Simon here:

http://www.mathworks.com/matlabcentral/answers/22144-c-mex-file-crashes-matlab-on-64bit-linux-but-not-32-bit-windows-but-program-runs-fine-outside-ma

> Or you could debug the code on one of the systems where
> you have familiar debuggers. The coding error will be
> the same on all platforms.
>

My specific problem, as stated, was that the error did not occur on all platforms. Only on 64Bit Linux, and only when compiled as a matlab mex file, rather than being called from a main function in a standalone program. So I'm not sure what you mean?

> > I believe the problem could be related to calls to the 'free' function. Are there any known problems with this?
>
> The obvious problem would be to free the same pointer twice.
> Which is one form of a rogue pointer. (There are several.)

The actual problem was I was trying to 'free' memory which pointed to NULL.

Thanks for the help anyway!

On 24 Nov, 13:48, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> > Or you could debug the code on one of the systems where
> > you have familiar debuggers. The coding error will be
> > the same on all platforms.
>
> My specific problem, as stated, was that the error did not occur on all platforms. Only on 64Bit Linux, and only when compiled as a matlab mex file, rather than being called from a main function in a standalone program. So I'm not sure what you mean?

A rogue pointer is a pointer that points somewhere else than
you, the programmer, thinks it does. Where that 'other' location
might be, varies from situation to situation (between platforms,
compiler mode, MEX&standalone,...) and the concequences of that
error varies depends on the situation and what you attempt to do.

If the pointer refers to not allocated space, then a seg fault
will occur when you try dereferncing it.

If the pointer points to allocated memory and you read data,
you will read invalid data and the computation results downstream
will give invalid results.

If the pointer points to allocated memory and you attempt to
write to th elocation, you might cause some program module
that is totally unrelated to where the coding error occurs,
cause a seg fault.

Freeing null pointers is the easiest such error to find,
so if that was the cause of problem you might count yourself
lucky. The somewhat disturbing question is what other errors
might reside in a code where the most trivial of all rogue
pointers have been discovered.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message <9aba748a-9eef-43b6-a2e4-8b8896125876@u5g2000vbd.googlegroups.com>...
> On 24 Nov, 13:48, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> > > Or you could debug the code on one of the systems where
> > > you have familiar debuggers. The coding error will be
> > > the same on all platforms.
> >
> > My specific problem, as stated, was that the error did not occur on all platforms. Only on 64Bit Linux, and only when compiled as a matlab mex file, rather than being called from a main function in a standalone program. So I'm not sure what you mean?
>
> A rogue pointer is a pointer that points somewhere else than
> you, the programmer, thinks it does. Where that 'other' location
> might be, varies from situation to situation (between platforms,
> compiler mode, MEX&standalone,...) and the concequences of that
> error varies depends on the situation and what you attempt to do.
>
> If the pointer refers to not allocated space, then a seg fault
> will occur when you try dereferncing it.
>
> If the pointer points to allocated memory and you read data,
> you will read invalid data and the computation results downstream
> will give invalid results.
>
> If the pointer points to allocated memory and you attempt to
> write to th elocation, you might cause some program module
> that is totally unrelated to where the coding error occurs,
> cause a seg fault.
>
> Freeing null pointers is the easiest such error to find,
> so if that was the cause of problem you might count yourself
> lucky. The somewhat disturbing question is what other errors
> might reside in a code where the most trivial of all rogue
> pointers have been discovered.
>
> Rune

in this code the functions 'malloc' and 'free' are used only to generate some input for an old 'C' file routine (triangle.c in the example code) in two places. The rest of the code was mostly written by a more experienced C++ programmer, and has been very extensively tested. I think if I clean up my own additions, there is some hope it will be safe, but we shall see.

 

On 24 Nov, 14:47, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <9aba748a-9eef-43b6-a2e4-8b8896125...@u5g2000vbd.googlegroups.com>...
> > On 24 Nov, 13:48, "Richard Crozier" <r.croz...@ed.ac.uk> wrote:
> > > > Or you could debug the code on one of the systems where
> > > > you have familiar debuggers. The coding error will be
> > > > the same on all platforms.
>
> > > My specific problem, as stated, was that the error did not occur on all platforms. Only on 64Bit Linux, and only when compiled as a matlab mex file, rather than being called from a main function in a standalone program. So I'm not sure what you mean?
>
> > A rogue pointer is a pointer that points somewhere else than
> > you, the programmer, thinks it does. Where that 'other' location
> > might be, varies from situation to situation (between platforms,
> > compiler mode, MEX&standalone,...) and the concequences of that
> > error varies depends on the situation and what you attempt to do.
>
> > If the pointer refers to not allocated space, then a seg fault
> > will occur when you try dereferncing it.
>
> > If the pointer points to allocated memory and you read data,
> > you will read invalid data and the computation results downstream
> > will give invalid results.
>
> > If the pointer points to allocated memory and you attempt to
> > write to th elocation, you might cause some program module
> > that is totally unrelated to where the coding error occurs,
> > cause a seg fault.
>
> > Freeing null pointers is the easiest such error to find,
> > so if that was the cause of problem you might count yourself
> > lucky. The somewhat disturbing question is what other errors
> > might reside in a code where the most trivial of all rogue
> > pointers have been discovered.
>
> > Rune
>
> in this code the functions 'malloc' and 'free' are used only to generate some input for an old 'C' file routine (triangle.c in the example code) in two places. The rest of the code was mostly written by a more experienced C++ programmer, and has been very extensively tested. I think if I clean up my own additions, there is some hope it will be safe, but we shall see.

Well, the problem with rogue pointersis that
unless they seg fault, they are likely to pass
any tests you might throw at them. A test
would go as follows:

1) Allocate memory
2) Write something to that memory
3) Read data back from the memory
4) Compare and see that what you read
   back equals what you wrote
5) Deallocate the memory

If something goes wrong in this process in a way
that does not case a seg fault, the code will
pass the test.

If ypu mean "the code has worked without problems
for a long time" it only means that you haven't
*discovered* any poblems. It does *not* mean that
there are no problems to be discovered.

Rune