Reputation: 284
I have custom C bindings called from Matlab and sometimes I get a segmentation fault. How can I identify in my source code what the corresponding statement is producing the SEGFAULT?
My C function is called Pairing in the source file Pairing.c
Stack Trace (from fault):
[ 0] 0x00007fff6bc76d00 Pairing.mexa64+00015616
[ 1] 0x00007fff6bc74330 Pairing.mexa64+00004912 mexFunction+00001862
[ 2] 0x00007fffe2b4f213 MATLAB/R2020a/bin/glnxa64/libmex.so+00582163
The result of nm -a Pairing.mexa64 | grep ' N '
is
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_str
Upvotes: 1
Views: 349
Reputation: 1544
here is my trick (works every single time), run this in a terminal window
matlab -nojvm -nosplash -r 'my_script' -D"valgrind --error-limit=no --tool=memcheck -v --log-file=valgrind.log"
preferably run this under Linux or Mac, but you can also do this in Windows using cygwin64/msys2. Need to install valgrind
before use - once it dumps the log in valgrind.log, open it using a text editor, and you can see all memory errors captured by valgrind.
for CUDA codes, you can also replace the valgrind command and parameters by cuda-memcheck, does something similar, but for the GPU.
make your test script my_script.m
very simple, for example, load a .mat file, and then call your mex function immediately to avoid lengthy overhead.
Upvotes: 3
Reputation: 284
The way I solved it was following these steps
1) Use objdump -d Pairing.mexa64 > Pairing_obj
.
2) Translate 00015616 to hex=0x3d00.
3) Find the relevant statement and recognize the produced assembly.
4) Realize this is the first time a certain variable is dereferenced.
I am still looking for some way that this could be done easier.
Upvotes: 0