在64位linux上,C++ Mex文件崩溃,但不是32位windows,但是程序运行在matlab之外。

时间:2022-09-06 15:05:16

WARNING The code I provide in my question may crash matlab AND your machine!!!

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.

我已经编写了一个mex网关函数到一个c++类。如果我使用R2008a在32位windows上编译这个mex函数,我没有问题。如果我编译并运行Matlab R2011a,运行64位的科学Linux (Red Hat enterprise Linux的一个版本),在调用mexfunction时,它会带有一个segfault,尽管它似乎在程序中运行了一半。c++类可以在没有错误的两个平台上编译和运行(带有一个主函数)。我在windows机器上使用Microsoft Visual c++ Express Edition,在Linux机器上使用gcc 4.4.5。

What is the cause of this and can I fix it?

这是什么原因,我能修复它吗?

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, 10kB). The file fmeshersetup.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.

一个包含复制问题所需的代码和数据文件的zip文件可以从http://www.see.y.ac.uk/ ~s0237326/downloads/mexcrash.zip下载。这个zip文件包含.m和.cpp源代码,以及用于测试的文本文件(Temp.fem, 10kB)。文件fmeshersetup。m显示了我用来编译的命令。文件Test_mexfmesher。m使用适当的输入进行测试。mex网关的功能是墨西哥。cpp,它调用fmesher类,它由fmesher目录中的文件组成。

There are a total of 13 C++ source files, which is a bit much to expect someone to debug, even the particular line on which the segfault occurs woud be of interest.

总共有13个c++源文件,这有点让人想要调试,即使是segfault发生的特定行也会引起兴趣。

Unfortunately I do not have access to a graphical debugger on 64bit linux that can interface with Matlab, and was hoping someone would immediately see the problem, or it would be a known problem. As stated, when run not as a mex file, the program runs fine, so I cannot locate the error in another tool, and I'm not very familiar with gdb. I believe the problem might be related to a calls to the C++ function 'free'.

不幸的是,我无法访问64位linux上的图形调试器,它可以与Matlab进行交互,希望有人能立即看到问题,或者是已知的问题。如前所述,当运行不是一个mex文件时,程序运行良好,所以我不能在另一个工具中定位错误,而且我对gdb不太熟悉。我认为这个问题可能与对c++函数“free”的调用有关。

Below is a backtrace from the segfault:

下面是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

1 个解决方案

#1


3  

You have attempted to use 'free' to free memory with a pointer which actually points to NULL. A careful programmer would check if this is the case before attempting to use free. Some libraries will have an automatic check for this.

您尝试使用一个指向NULL的指针来使用“free”来释放内存。一个细心的程序员会在尝试使用免费软件之前检查这是否属实。有些库会自动检查这个。

The reason you did not notice this when compiling as a standalone may be due to the fact that matlab uses its own libstdc++ (stored in /opt/matlab-2011a/bin/glnxa64/libstdc++.so.6) instead of the main one (stored in /usr/lib/x86_64-linux-gnu/).

您在编译时没有注意到这一点,可能是因为matlab使用了自己的libstdc++(存储在/opt/matlab-2011a/bin/glnxa64/libstdc+ .so.6)而不是main(存储在/usr/lib/x86_64-linux-gnu/)。

If you are sudoer, You should force matlab to use the main libstdc++, this can solve many problems with mex files:

如果您是sudoer,您应该强制使用matlab来使用主要的libstdc++,这可以解决许多与mex文件有关的问题:

cd /opt/matlab-2011a/bin/glnxa64/
sudo mkdir old
sudo mv libstdc++.so.6* old
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 libstdc++.so.6

#1


3  

You have attempted to use 'free' to free memory with a pointer which actually points to NULL. A careful programmer would check if this is the case before attempting to use free. Some libraries will have an automatic check for this.

您尝试使用一个指向NULL的指针来使用“free”来释放内存。一个细心的程序员会在尝试使用免费软件之前检查这是否属实。有些库会自动检查这个。

The reason you did not notice this when compiling as a standalone may be due to the fact that matlab uses its own libstdc++ (stored in /opt/matlab-2011a/bin/glnxa64/libstdc++.so.6) instead of the main one (stored in /usr/lib/x86_64-linux-gnu/).

您在编译时没有注意到这一点,可能是因为matlab使用了自己的libstdc++(存储在/opt/matlab-2011a/bin/glnxa64/libstdc+ .so.6)而不是main(存储在/usr/lib/x86_64-linux-gnu/)。

If you are sudoer, You should force matlab to use the main libstdc++, this can solve many problems with mex files:

如果您是sudoer,您应该强制使用matlab来使用主要的libstdc++,这可以解决许多与mex文件有关的问题:

cd /opt/matlab-2011a/bin/glnxa64/
sudo mkdir old
sudo mv libstdc++.so.6* old
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 libstdc++.so.6