MATLAB: How to determine if segmentation violation is caused by MATLAB function or user-defined function

deserializationexceptionsegmentation violationstack trace

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

Best Answer

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 "[0]". 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.
Related Question