CODEWITHSUNDEEP
linuxmatlabdebugginggdbmex
condor
condor

Reputation: 22

Cannot step into MEX function

Question:

I cannot step into my MEX function. What am I doing wrong? The obvious answer is the SEGSEGV and SIGUSR1 but it would be good to get an insight on why that is. Atleast for the SIGUSR1

Environment - x86_64 linux Software - Matlab 2012a Debugger - GDB

There is a bit of preface since I think it is relevant to answering the question and knowing the holes in my understanding.

Compiled mex file with debug flag

start gdb with matlab as the executable and with -Dgdb (gdb set as debugger)

bash:>matlab -Dgdb

run matlab in command line 

(gdb) run -nojvm

In the course of starting up Matlab I see a bunch of "Missing separate debuginfo for ...*.so" and also hits a handful of segmentation faults (SIGSEGV)

I set gdb segmentation fault signal handling to print but don't stop.

gdb>handle SIGSEGV nostop print pass
gdb>handle SIGUSR1 nostop print pass

Signal       Stop    Print     Pass     Description
SIGSEGV       No     Yes        Yes     Segmentation fault
SIGUSR1       No     Yes        Yes     User defined signal 1

After disable SIGSEGV i'm able to get to the Matlab command line where all seems to be good and Matlab appears to be operational.

Enable mex debugging

matlab>>dbmex on
matlab>>yprime(1,[1,2,3,4])


Program received signal SIGUSR1, User defined signal 1.

MEX FILE: /home/user/test/prime/yprime.mexa64 entry point located 
at address 0xde5e3a60
Add breakpoints at the debugger prompt and issue a "continue" to resume 
execution of MATLAB.


ans =

    2.0000    8.9685    4.0000   -1.0947

Based on the output ans we have already passed through yprime() mex routine and returned the result back to Matlab.

What happens if I don't bypass SIGUSR1?

If I don't bypass the SIGUSR1 I get the following output:

>> yprime(1,[1,2,3,4])         

Program received signal SIGUSR1, User defined signal 1.
0x0000003c83c0b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from    /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install 
glibc-2.12-1.149.el6_6.5.x86_64 libICE-1.0.6-1.el6.x86_64 
libSM-1.2.1-2.el6.x86_64 libX11-1.6.0-2.2.el6.x86_64 
libXau-1.0.6-4.el6.x86_64 libXcursor-1.1.14-2.1.el6.x86_64 
libXext-1.3.2-2.1.el6.x86_64 libXfixes-5.0.1-2.1.el6.x86_64 
libXmu-1.1.1-2.el6.x86_64 libXrender-0.9.8-2.1.el6.x86_64 
libXt-1.1.4-6.1.el6.x86_64 libuuid-2.17.2-12.18.el6.x86_64 
libxcb-1.9.1-2.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64 
nss-softokn-freebl-3.14.3-22.el6_6.x86_64 zlib-1.2.3-29.el6.x86_64


(gdb) bt
#0  0x0000003c83c0b5bc in pthread_cond_wait@@GLIBC_2.3.2 () 
           from /lib64/libpthread.so.0
#1  0x00007f2440f10774 in mcr_run_main(...l) ()
           from /opt/matlab_2012a/bin/glnxa64/libmwmcr.so
#2  0x00000000004026e0 in ?? ()
#3  0x0000003c8381ed5d in __libc_start_main () from /lib64/libc.so.6
#4  0x0000000000402579 in ?? ()
#5  0x00007ffffc6f3678 in ?? ()
#6  0x000000000000001c in ?? ()
#7  0x0000000000000002 in ?? ()
#8  0x00007ffffc6f4a9b in ?? ()
#9  0x00007ffffc6f4ac0 in ?? ()
#10 0x0000000000000000 in ?? ()

Upvotes: 0

Views: 333

Answers (2)

Ben Voigt
Ben Voigt

Reputation: 283773

  1. Do not set nostop on SIGUSR1, let it break into the debugger.

  2. Read what MATLAB told you to do:

Add breakpoints at the debugger prompt and issue a "continue" to resume execution of MATLAB.

There is no need to backtrace (bt) when SIGUSR1 is received. It isn't an error that needs to be debugged, just a chance for you to set breakpoints on your MEX file now that it has been loaded.

Upvotes: 1

Employed Russian
Employed Russian

Reputation: 213799

I cannot step into my MEX function. What am I doing wrong?

You never showed trying to step into your function.

You should probably execute it once (keeping the SIGSEGV and SIGUSR1 disposition that you have), then set a breakpoint on the function and call it again. This time, GDB should stop inside your function.

Upvotes: 0

Related Questions