Prev: problem with symbolic integration
Next: How can I compare 2 surfaces??
From: Michael on 4 May 2010 03:19
As stated in some other message on the Newsreader, I implemented a subroutine that needs two nested for-loops in CMEX, doing the stuff inside the loop still in MATLAB using mexEvalString. I compiled the C-code using "mex -largeArrayDims -O mexFile.c". My operating system is Windows XP x64, MATLAB is used in version R2009b.

When I tried the function, it ran for about 7 hours (total running time of 12-14 hours expected), before a MATLAB System Error was issued:

MATLAB crash file:E:\DOCUME~1\Michael\LOKALE~1\Temp\matlab_crash_dump.1936
------------------------------------------------------------------------
Segmentation violation detected at Tue May 04 00:08:38 2010
------------------------------------------------------------------------

Configuration:
MATLAB Version: 7.9.0.529 (R2009b)
MATLAB License: 172356
Operating System: Microsoft Windows XP x64
Window System: Version 5.2 (Build 3790: Service Pack 2)
Processor ID: x86 Family 6 Model 7 Stepping 6, GenuineIntel
Virtual Machine: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM mixed mode
Default Encoding: windows-1252

Fault Count: 1

Register State:
rax = 0000000000000004 rbx = 00000000000006e1
rcx = 000000000113ce34 rdx = 0000000001dc2d10
rbp = 0000000000001770 rsi = 000000004ccb7000
rdi = 000000000113ceb9 rsp = 000000000113ce00
r8 = 0000000000000007 r9 = 0000000000000000
r10 = 0000000078130000 r11 = 0000000000000200
r12 = 0000000000000178 r13 = 000000004ccb5480
r14 = 00000000000005dc r15 = 0000000005140000
rip = 00000000051410c5 flg = 0000000000010202

Stack Trace:
[ 0] 00000000051410C5 mexFile.mexw64+004293 (mexFunction+000197)
[ 1] 0000000005143468 mexFile.mexw64+013416 (mexFunction+009320)
[ 2] 0000000077EF47DD ntdll.dll+215005 (RtlDetermineDosPathNameType_U+000765)
[ 3] 000000007C8340A3 libmex.dll+016547 (mexRunMexFile+000131)
[ 4] 000000007C83201F libmex.dll+008223 (inSwapMexfileReader+000223)
[ 5] 000000007C8321E4 libmex.dll+008676 (inSwapMexfileReader+000676)
[ 6] 000000007ABC6195 m_dispatcher.dll+418197 (Mfh_file::dispatch_fh+000325)
[ 7] 000000007AB61B25 m_dispatcher.dll+006949 (Mfunction_handle::dispatch+000021)
[ 8] 000000007B924B56 m_interpreter.dll+5131094 (init_cleaner+232886)
[ 9] 000000007B928FE8 m_interpreter.dll+5148648 (init_cleaner+250440)
[ 10] 000000007B929F45 m_interpreter.dll+5152581 (init_cleaner+254373)
[ 11] 000000007B60238D m_interpreter.dll+1844109 (inRunLoadObjFunctionC+1188365)
[ 12] 000000007B671627 m_interpreter.dll+2299431 (inRunLoadObjFunctionC+1643687)
[ 13] 000000007B671745 m_interpreter.dll+2299717 (inRunLoadObjFunctionC+1643973)
[ 14] 000000007B86E352 m_interpreter.dll+4383570 (inRunLoadObjFunctionC+3727826)
[ 15] 000000007B49F0CA m_interpreter.dll+389322 (QueryMLFcnTable_m_interpreter+129082)
[ 16] 000000007B4F61F7 m_interpreter.dll+745975 (inRunLoadObjFunctionC+090231)
[ 17] 000000007B4CBD19 m_interpreter.dll+572697 (QueryMLFcnTable_m_interpreter+312457)
[ 18] 000000007B4CBD45 m_interpreter.dll+572741 (QueryMLFcnTable_m_interpreter+312501)
[ 19] 000000007ABC6195 m_dispatcher.dll+418197 (Mfh_file::dispatch_fh+000325)
[ 20] 000000007AB61B25 m_dispatcher.dll+006949 (Mfunction_handle::dispatch+000021)
[ 21] 000000007B4D6D62 m_interpreter.dll+617826 (QueryMLFcnTable_m_interpreter+357586)
[ 22] 000000007B490C05 m_interpreter.dll+330757 (QueryMLFcnTable_m_interpreter+070517)
[ 23] 000000007B4945ED m_interpreter.dll+345581 (QueryMLFcnTable_m_interpreter+085341)
[ 24] 000000007B494AAF m_interpreter.dll+346799 (QueryMLFcnTable_m_interpreter+086559)
[ 25] 000000007B457AB1 m_interpreter.dll+096945 (inEvalCmdWithLocalReturn+000065)
[ 26] 0000000078EC87EA bridge.dll+034794 (mnInitializeParser+000218)
[ 27] 0000000078EC92D8 bridge.dll+037592 (mnParser+000456)
[ 28] 000000007AD23DA4 mcr.dll+212388 (mcrInstance::mnParser_on_interpreter_thread+000036)
[ 29] 000000007AD02217 mcr.dll+074263 (mcr::runtime::InterpreterThreadFactory::~InterpreterThreadFactory+022903)
[ 30] 000000007ACFEC02 mcr.dll+060418 (mcr::runtime::InterpreterThreadFactory::~InterpreterThreadFactory+009058)
[ 31] 000000000174CB6C uiw.dll+379756 (UIW_IsUserMessage+000108)
[ 32] 000000000174D523 uiw.dll+382243 (ws_ProcessPendingEventsWaitForWindows+000499)
[ 33] 0000000077CCB0F8 USER32.dll+700664 (DdePostAdvise+002056)
[ 34] 0000000077C5194A USER32.dll+203082 (UnhookWindowsHookEx+000362)
[ 35] 0000000077C4FCD1 USER32.dll+195793 (TrackPopupMenuEx+000785)
[ 36] 0000000077EF318F ntdll.dll+209295 (KiUserCallbackDispatcher+000031)
[ 37] 0000000077C43D9A USER32.dll+146842 (GetWindowLongPtrW+000282)
[ 38] 0000000077C27F03 USER32.dll+032515 (GetMessageA+000067)
[ 39] 0000000001716917 uiw.dll+157975 (UIW_SetCurrentDialog+000855)
[ 40] 000000000174CF51 uiw.dll+380753 (ws_ProcessOneEventBlocking+000433)
[ 41] 000000000174D1E3 uiw.dll+381411 (ws_ProcessPendingEvents+000147)
[ 42] 000000007AD0476C mcr.dll+083820 (mcr::runtime::InterpreterThreadFactory::~InterpreterThreadFactory+032460)
[ 43] 000000007AD04D09 mcr.dll+085257 (mcr::runtime::InterpreterThreadFactory::~InterpreterThreadFactory+033897)
[ 44] 000000007AD0522E mcr.dll+086574 (mcr::runtime::InterpreterThreadFactory::~InterpreterThreadFactory+035214)
[ 45] 000000007AD06A32 mcr.dll+092722 (mcr::runtime::InterpreterThreadFactory::runThreadFunction+001554)
[ 46] 0000000077D596AC kernel32.dll+104108 (BaseProcessStart+000044)

This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for information
on debugging MEX-files.
[...]


Here's the (shortened) code of the MEX-file:

#include <string.h>
#include "mex.h"

typedef unsigned int* uint_ptr; // definition of pointer-to-uint type for sake of clarity

/*MAIN FUNCTION*************************************************/
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
uint_ptr mask;
mwSize rows, cols;
int i, j;
char text[200];
char iBuffer[5];
char jBuffer[5];

mask = mxGetData(prhs[0]);
rows = mxGetM(prhs[0]);
cols = mxGetN(prhs[0]);

for(j = 1; j <= cols; j++)
{
sprintf(jBuffer, "%d", j);
i = 1;

for(i = 1; i <= rows; i++)
{
sprintf(iBuffer, "%d", i);

// Masking of unreliable pixels
if(!mask[(rows*(j-1))+(i-1)]) continue;

// Getting the time t:
strcpy(text, "t = (32768 - (");
strcat(text, iBuffer);
strcat(text, "+offset))*dt + t0;");
mexEvalString(text);
text[0] = '\0';

// Getting the range R:
strcpy(text, "R = (");
strcat(text, jBuffer);
strcat(text, "-1 + offset) * dR + R0;");
mexEvalString(text);
text[0] = '\0';

// Getting the flight parameters from the time
mexEvalString("S = getSensorPosition(t,positionPolynomial);");
mexEvalString("V = getSensorVelocity(t,velocityPolynomial);");

// Solving some nonlinear equation system using fsolve (wrapped) in fsolveWrapper
strcpy(text, "result((");
strcat(text, jBuffer);
strcat(text, "-1)*");
strcat(text, "rows +");
strcat(text, iBuffer);
strcat(text, ",:) = fsolveWrapper(x0,image(");
strcat(text, iBuffer);
strcat(text, ",");
strcat(text, jBuffer);
strcat(text, "),R,S,V);");
mexEvalString(text);
text[0] = '\0';

iBuffer[0] = '\0';
}
jBuffer[0] = '\0';
}
free(text);
free(iBuffer);
free(jBuffer);
free(mask);
}


All the variables that are used exist in the MATLAB workspace, even the result array is pre-allocated in MATLAB. In MATLAB, "mask" is a 2D uint8 array containing only 1s and 0s, determining which pixels of "image" shall be processed.

Any idea out there what might cause the segmentation violation?
From: Bruno Luong on 4 May 2010 04:00
Intriguing, why you are using exclusively mex with MexEvalString? You will add overhead (with respect to pure Matlab code) with a significant increase of code complexity. What are you trying to do????

Bruno
From: Michael on 4 May 2010 04:53
"Bruno Luong" <b.luong(a)fogale.findmycountry> wrote in message <hrok6m$c7d$1(a)fred.mathworks.com>...
> Intriguing, why you are using exclusively mex with MexEvalString? You will add overhead (with respect to pure Matlab code) with a significant increase of code complexity. What are you trying to do????
>
> Bruno

I'm doing so only in this very case, usually I do try to code everything I want to outsource in C when using MEX.

But here I want to make use of MATLAB's very comfortable and fast "fsolve" routine while using several small (and fast) functions I have already coded in MATLAB before. In addition to that I must admit I was a little to lazy to take care about all the variable passing from and to MATLAB - having everything I need stored in MATLAB's workspace environment.
From: Bruno Luong on 4 May 2010 05:26
"Michael " <michael.schmittNOSPAM(a)bv.tum.de> wrote in message <hron9f$2k3$1(a)fred.mathworks.com>...
> "Bruno Luong" <b.luong(a)fogale.findmycountry> wrote in message <hrok6m$c7d$1(a)fred.mathworks.com>...

>
> But here I want to make use of MATLAB's very comfortable and fast "fsolve" routine while using several small (and fast) functions I have already coded in MATLAB before. In addition to that I must admit I was a little to lazy to take care about all the variable passing from and to MATLAB - having everything I need stored in MATLAB's workspace environment.

The question is more why you are using MEX? I don't see a single C-code that do any calculation. But anyway, it's your business.

Here is something more on topic: why you are FREE a local string on the stack? I'm surprised it does make an instantaneous crash. They are not allocated with MALLOC. So remove the FREE.

Bruno
From: Michael on 4 May 2010 06:29
Simple answer: I have tested this procedure on some small dataset (100 x 100 pixels) and had a speed gain of about 25%. Although I need to test the reliability of the CMEX implementation...
 |  Next  |  Last
Pages: 1 2 3
Prev: problem with symbolic integration
Next: How can I compare 2 surfaces??