Why does Matlab crashes between mex calls?

Hi,

I have mex files around 15 which are linked to same dll. When I run a script using those mex functions, matlab is getting crashed inconsistently with "Access violation". I think the context between the mex calls is not maintaining properly. What to do in order to avoid that.

Thanks.

Answer 1

[Jan]

The asnwer is easy: One or more of the called Mex functions copntains a bug. This happens frequently, because C-code is very susceptible, e.g. if it was written and tested under a 32 bit version of the compliler and runs with 64 bit addressing now. Note that an access violation can happens directly inside the code, or even later, if the C code has created invalid Matlab variables.

You have to find out, which C function causes the crashes. Then post the code such that the readers can suggest an improvement.

[Prasanna]

Both mex and dll are written in cpp. I have compiled the dll in 64 bit version only.

Some mex calls are working fine some times but not all the times. Suppose if there is a bug, then why it is working sometimes.

One more thing is that the whole environment is working properly without any single crash in linux platform.

[James Tursa]

As Jan wrote, memory can be corrupted at one time but the crash doesn't happen until later when the memory gets accessed. It only appears to be working sometimes. Regardless, we can't help you unless we can see the source code.

[Jan]

See https://en.wikipedia.org/wiki/C_data_types. Look at this example:

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
  long *p;
  plhs[0] = mxDuplicateArray(prhs[0]);
  p    = (long) mxGetData(plhs[0]);
  p[0] = 1;
  p[1] = 2;
}

Consider the definition of "long" in C: A signed integer with at least 32 bits. It might have 64 bits also, because this depends on the compiler. If the input is a UINT32, the code works with compilers defining long with 32 bits. But if long has 64 bits, the 2 is written to unreserved memory. Perhaps this memory is not allocated and nobody cares, but it is likely that some important information is overwritten. Sometimes the original data might equal the accidentally written value, this is random. Therefore the code might crash directly, work sometimes or let Matlab crash later, when the overwritten value is used.

Compiled "for 64 bit" or "for linux" is not enough to predict, what was applied exactly. It depends on the "data-type model" of the compiler, see e.g. https://en.wikipedia.org/wiki/64-bit_computing: MSVC is "LLP64", most linux compilers are "LP64".

The only solution is to use strictly defined data types, e.g. uint32_T instead of long for the data. In addition the opposite is true for the pointer arithmetics: size_t, mwSize, mwIndex is secure, while any assumption about the bit-width of the pointer types are dangerous. The C sources must be adjusted to work reliably.

"Working sometimes" is a bad problem with C: This language allows to access the memory directly and there are no checks if the bytes have been allocated before. Avoiding the checks is much faster, but dangerous, if the programmer does not exactly know, what he is doing.

Either ask the author, or if it is possible post the codes here. Maybe only small changes are required, but 15 functions might mean, that it is too much for a small favor in the forum.

[Prasanna]

okay.

I should not post my code, it's confidential. Is the problem might be in Mex or c++ dll?

[José-Luis]

In C++

 std::vector<double> bla = {0.0,0.1};
 double IwannaDie = bla[3]; //Adios amigo

It can be very many things. Your best bet is to use a debugger. Every other approach is more or less a waste of time unless it's something obvious like the above.

[Prasanna]

How to debug the dll which is linked to mex. I am able to debug mex but not dll. I have visual studio 2012 installed on my computer and I have the source code of the dll also.