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?
|
|
0
|
|
|
|
Reply
|
 Michael
|
5/4/2010 7:19:07 AM |
|
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
|
|
|
0
|
|
|
|
Reply
|
Bruno
|
5/4/2010 8:00:22 AM
|
|
"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hrok6m$c7d$1@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.
|
|
|
0
|
|
|
|
Reply
|
Michael
|
5/4/2010 8:53:03 AM
|
|
"Michael " <michael.schmittNOSPAM@bv.tum.de> wrote in message <hron9f$2k3$1@fred.mathworks.com>...
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hrok6m$c7d$1@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
|
|
|
0
|
|
|
|
Reply
|
Bruno
|
5/4/2010 9:26:03 AM
|
|
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...
|
|
|
0
|
|
|
|
Reply
|
Michael
|
5/4/2010 10:29:05 AM
|
|
"Michael " <michael.schmittNOSPAM@bv.tum.de> wrote in message <hrosth$5r7$1@fred.mathworks.com>...
> 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...
I have doubt if you do the correct timing (which is not trivial to get it right as it seems to be, believe me).
To be certain I have tried my own test of calling a function directly from Matlab and from mex. The timing speak for itself, the overhead of mexEvalString is HUGE.
function bar
tic
for n=1:10000;
r = foo;
end
toc % 0.005447 seconds
clear r
tic
for n=1:10000;
callfoo;
end % Elapsed time is 0.845930 seconds.
toc
end % bar
function r = foo
r = 1.0;
end % foo
// callfoo.c
#include <string.h>
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) {
char text[200];
strcpy(text, "r = foo;");
mexEvalString(text);
return;
} // callfoo.c
Bruno
|
|
|
0
|
|
|
|
Reply
|
Bruno
|
5/4/2010 10:57:03 AM
|
|
You may be right - I don't really know whether it's really worthwhile. That's why I wanted to give it a try.
Nevertheless you should be careful with your comparison: I do the for-loop within C/MEX! With for-loops being terrifyingly slow in MATLAB, I would believe you would have better timing using the following test:
#include <string.h>
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) {
char text[200];
int i;
for(i = 0; i<=10000;i++)
{
strcpy(text, "r = foo;");
mexEvalString(text);
}
return;
} // callfoo.c
Nevertheless this wasn't my original problem. ;) Any help on the segmentation violation would be appreciated.
|
|
|
0
|
|
|
|
Reply
|
Michael
|
5/4/2010 11:51:05 AM
|
|
>
> Nevertheless this wasn't my original problem. ;) Any help on the segmentation violation would be appreciated.
Have you seen my comments on FREE? Those are very wrong.
Bruno
|
|
|
0
|
|
|
|
Reply
|
Bruno
|
5/4/2010 12:00:20 PM
|
|
"Michael " <michael.schmittNOSPAM@bv.tum.de> wrote in message <hrp1n9$er5$1@fred.mathworks.com>...
> I would believe you would have better timing using the following test:
Why don't you do it yourself?
Bruno
|
|
|
0
|
|
|
|
Reply
|
Bruno
|
5/4/2010 12:17:06 PM
|
|
"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hrp382$o7c$1@fred.mathworks.com>...
> "Michael " <michael.schmittNOSPAM@bv.tum.de> wrote in message <hrp1n9$er5$1@fred.mathworks.com>...
> > I would believe you would have better timing using the following test:
>
> Why don't you do it yourself?
>
> Bruno
Because I already did a tic-toc test and experienced a speed gain of 25% (cf. my previous messages). With my last message I only replied to your (not sufficient) argumentation.
|
|
|
0
|
|
|
|
Reply
|
Michael
|
5/4/2010 1:05:19 PM
|
|
"Michael " <michael.schmittNOSPAM@bv.tum.de> wrote in message <hrp62e$49h$1@fred.mathworks.com>...
>
> Because I already did a tic-toc test and experienced a speed gain of 25% (cf. my previous messages). With my last message I only replied to your (not sufficient) argumentation.
You are funny Michael, earlier you ask ME to do the test order to convince YOU; please let me quote "...I would believe you would have better timing using the following test". That shows you don't really know what take time in the program, let alone knowing why. Yes I have done the test, it's no point for me to show the result here. It only takes two modifications and rerun the code. No big deal to do it, anyone can do it. The person who needs to be convinced is not me.
Michael, if you are unable to show your test to backup what you claim, or avoid the simplest test that has been suggested, and avoid to face the fact that you are in the wrong path, the discussion ends here.
Bruno
|
|
|
0
|
|
|
|
Reply
|
Bruno
|
5/4/2010 1:29:04 PM
|
|
"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hrp7f0$817$1@fred.mathworks.com>...
> "Michael " <michael.schmittNOSPAM@bv.tum.de> wrote in message <hrp62e$49h$1@fred.mathworks.com>...
>
> >
> > Because I already did a tic-toc test and experienced a speed gain of 25% (cf. my previous messages). With my last message I only replied to your (not sufficient) argumentation.
>
> You are funny Michael, earlier you ask ME to do the test order to convince YOU; please let me quote "...I would believe you would have better timing using the following test". That shows you don't really know what take time in the program, let alone knowing why. Yes I have done the test, it's no point for me to show the result here. It only takes two modifications and rerun the code. No big deal to do it, anyone can do it. The person who needs to be convinced is not me.
>
> Michael, if you are unable to show your test to backup what you claim, or avoid the simplest test that has been suggested, and avoid to face the fact that you are in the wrong path, the discussion ends here.
>
> Bruno
Nor is it a problem for me to run the test PROPERLY, however, I do not need to test AGAIN, because I already did test my C/MEX implementation using tic/toc and experienced a speed gain of about 25%. Seems you don't want to understand me.
I do not need to be convinced, all I need is help on the segmentation violation problem. If it's the free(xxx) thing, I thank you for this tip, if not, I hope I will find some additional advice on my original question here.
|
|
|
0
|
|
|
|
Reply
|
Michael
|
5/4/2010 1:43:04 PM
|
|
For the sake of peace: Mea maxima culpa.
I did the following test:
tic
for m = 1 : 100
for n = 1 : 100
r = foo;
end
end
toc
clear r
tic
callfoo;
toc
with callfoo.c:
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) {
char text[200];
int m, n;
for(m = 0; m<100; m++)
{
for(n = 0; n<100; n++)
{
strcpy(text, "r = foo;");
mexEvalString(text);
}
}
return;
}
The MATLAB side of things took about 0.01 seconds, the mexEvalString implementation took about 0.86 seconds. Which really amazes me, since I definetely saw that speed gain for my original problem. Guess there must be something else wrong...
Bruno, please take my apologies! We see: mexEvalString is (unfortunately!!) very slow...
|
|
|
0
|
|
|
|
Reply
|
Michael
|
5/4/2010 2:02:19 PM
|
|
|
12 Replies
427 Views
(page loaded in 0.348 seconds)
|
Search |
Post Question |
Groups |
Stream |
About |
Register
197277 articles. 
485 followers. 