How to determine if segmentation violation is caused by MATLAB function or user-defined function?
99 views (last 30 days)
I understand its meaningless to post the stack trace of a segmentation violation here to find out the cause. However, I hope to find out how to determine that specific function name that causes the crash.
If the MEX-function belong to MATLAB, i can send the stack trace to MATLAB technical support. If the function is user-defined function, i can focus on the specific function code. Thanks!
Stack Trace: (Partial)
[ 0] 0000000001AC831D m_interpreter.dll+164637 (inNarginout+003981)
[ 1] 0000000007E01128 distcompdeserialize.mexw64+004392 (mexFunction+000296)
[ 4] 00000000020B7918 m_interpreter.dll+6387992 (inPathNotification::`vftable'+000728)
[ 15] 0000000002384E83 libmex.dll+020099 (mexRunMexFile+000131)
[ 16] 0000000002382DBC libmex.dll+011708 (inSwapMexfileReader+000220)
[ 17] 0000000002382F84 libmex.dll+012164 (inSwapMexfileReader+000676)
[ 18] 00000000023F3544 m_dispatcher.dll+341316 (Mfh_file::dispatch_fh+000340)
[ 19] 00000000023A1B65 m_dispatcher.dll+007013 (Mfunction_handle::dispatch+000021)
??? Error using ==> parallel_function at 587 Deserialization threw an exception
MarkB on 4 Apr 2011
The general way to read a stack trace is that each row indicates a function call, and the top one is the deepest/most recent function call before the crash as indicated by the "". From there, it lists the exe/dll/mex file with the problematic function call, in the case of frame "0", it is in "m_interpreter.dll". After that is the function within it being called. Depending on how the exe/dll/mex file was compiled, it may list the function name, or just the function's address (In this case it is just the address of the function). Lastly, it lists the arguments to the function and/or their addresses.
Given your particular stack trace, it looks like the break occurred somewhere in "m_interpreter.dll", but that does not necessarily mean that the problem is in that file. It could very well be a working function that was given invalid inputs, so it is worthwhile to check the other functions/dlls/mex files earlier in the stack trace as well.
More Answers (3)
Walter Roberson on 4 Apr 2011
I am not very familiar with those tracebacks, but it appears that a Mex file called back to Matlab in a parallel function, and that the parallel function had trouble interpreting the stream of data that it got that it needs to turn in to local objects and variables in order to work on the variables on the other core / thread. Does that situation sound familiar in terms of what you are doing with your mex files?