mex: valid c code crashes Matlab. (integer pointer)

This code compiles, but crashes Matlab. The same code written and compiled as straight c works fine.

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

 void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[])
{
  //int z =11;
  int *x = 1;
  *x = 14;
  printf("*x = %d\n", *x);
}

With this small change it works fine. Should I have expected this behavior?

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

 void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[])
{
  int z =11;
  int *x = &z;
  *x = 14;
  printf("*x = %d\n", *x);
}

[Gary Pajer]

This posted before I could finish:

Matlab R2015a,

OS X 10.11.6

Answer 1

[James Tursa]

You have a misunderstanding of pointers. This code:

int *x = 1;
*x = 14;

Does the following: The first line declares a variable named x that is of type pointer_to_int. It then initializes that pointer to the address value 1. I.e., x now points to the memory location associated with the address value of 1. This is an invalid memory location. The next line attempts to write the value of 14 to this invalid memory location. This results in a crash as expected. This code would not be expected to work as straight C code either. The fact that you apparently compiled it and got a result as a straight C program was pure luck, since the code is invalid. You wrote a 14 to an invalid memory location, and the results (if not an outright crash) are unpredictable. What is really at address 1 that you overwrote? It isn't even byte-aligned properly to hold a 4-byte int.

The changed code is very different:

int z =11;
int *x = &z;
*x = 14;

Here x is still a pointer_to_int, but you have initialized it to a valid memory location, namely the address of the int variable z. So the *x = 14 is writing the value 14 into a valid memory location (z now has the value 14). Perfectly fine.

This would also work fine since it initializes x to a valid memory location large enough to hold an int:

int *x;
x = mxMalloc(1*sizeof(*x));
*x = 14;
printf("*x = %d\n", *x);
mxFree(x);

[Gary Pajer]

You bet. (I wonder how much the misunderstanding of pointers has cost our economy.) But I did mistype. I understand your explanation, and indeed the code that fails in Matlab fails when compiled into a c program, and ditto for the code that works. But the code below does compile and run as a c program, but crashes Matlab. After seeing your malloc example, I don't understand why this works. It does generate a warning, but in my haste I didn't think to -Wall. At any rate, thanks for your patience and the education. I'm not a programmer by trade, and I struggle with pointers, arrays, etc.

int *x;
*x = 14;
printf("*x = %d\n", *x);

[James Tursa]

The code in your recent comment above is also invalid for a different but related reason. In this case x is still of type pointer_to_int, but it is uninitialized and contains a garbage value at runtime. I.e., the value of x is pointing to a "random" location in memory since it was never set. Dereferencing it in the next line and writing a value to that location is invalid. If that random location happens to not be flagged by the OS or otherwise overwrite something important, then the code will appear to run fine (apparently you clobbered something unimportant for the moment). But if the random memory location is checked or clobbers something important (e.g. apparently the case in the MATLAB code) you will get a crash. Bottom line is that the code is invalid in both cases, even if it appears to run OK in one case because of pure luck (back luck IMO since it would be better to crash immediately to alert you to the coding error). Code like this can appear to run fine ... then you include it in a different project and it crashes and you have no idea why it is suddenly crashing when it used to work fine!

It is often good programming practice to always initialize pointers when they are declared to either something valid or NULL. That way the code will definitely crash if you dereference a NULL and you will be alerted to the coding error. E.g., try this in your standalone C program:

int *x = NULL;  /* Initialize to an invalid address */
*x = 14;  /* This line should now crash your standalone program */
printf("*x = %d\n", *x);

To get a handle on the concept of uninitialized pointers, consider this code which does not use pointers:

int i;
printf("i = %d\n",i);

What would you expect the printed result to be? Garbage, right? Because i was never set to anything. It is easy to see in this simple int example. Same problem above with your pointer x ... you never set x but by dereferencing it you used its garbage value.

[Gary Pajer]

Great. Thanks for explaining. I hope I remember for the future.