Dereference of invalid pointer expression

[gypaete33]

Hello alls

I have an application that crashes when running in debug mode. Here is the error message :

NON-FATAL RUN-TIME ERROR: "SEKO_tools.c", line 67, col 9, thread id 11148: Out-of-bounds pointer arithmetic: 621 bytes (156 elements) past end of array.
FATAL RUN-TIME ERROR: "SEKO_tools.c", line 68, col 9, thread id 11148: Dereference of invalid pointer expression.

Attached to the post, a sample file to reproduce with CVI 2017.

The point is not to find a workaround but to understand why there is a problem.

Thanks

[rolfk]

static void tools_setValueInStruct(T_MessageIhm *i_messageIhm, int i_indexKey, float i_value)
{
		float *ptr 	= &(i_messageIhm->e1);
		ptr 		+= (i_indexKey);
		*ptr 		= i_value;
		
}

int main(int argc, char *argv[])
{
	char d[128];
	tools_setValueInStruct(&g_messageIhm, 156, 178.2);
	
	return 0;
}

This is VERY BAD C programming.

Basically you tell it to increase the ptr (which at that point is defined as a pointer to float) by 156 elements. I'm not going to do the math but apparently your total structure is NOT 156*4 bytes long seen from the e1 element.

But really what is this all about? your structure mixes and matches float and int values both scalar and inlined arrays! Will you for every value inside that structure that you might want to access every time calculate the right index? You could just as well write in assembly code then, that is not more complicated. Using a higher level language is to make your work easier not more complicated but then you need to use the right architecture.

[rolfk]

I just checked and while the value is theoretically within the buffer, you have of course a problem.

The ptr itself is simply a pointer to a float not to an array of float, even though it points into a larger variable that could validly reference the 156th element however at this point the runtme does only see a pointer to a single float. Strict? Yes sure! Wrong? Definitely not!

[gypaete33]

Thank you for your answer, Rolf.

I totally agree that this is very bad programming (I am not the author !). The code has been simplified in order to just reveal the problem and to hide what it really does. Originally, the big structure does not contain arrays but just a mixed list of floats and integers.

But I could not and still cannot understand why CVI is complaining about it as it does what it is intended to do.

But sure, we will improve it.

Alain

[rolfk · Accepted solution]

---

@gypaete33 wrote:

But I could not and still cannot understand why CVI is complaining about it as it does what it is intended to do.

---

Very simple!

float *ptr;

This declares strictly speaking a pointer to a single float value. It can be infered that if the pointer is valid it should point to at least a single float value, though with type casting not even that is guaranteed.

char c = 4;
float *f = (float*)&c;

For this the assumption that f points to a memory area big enough to hold a float is obviously not correct.

The LabWindows/CVI runtime debugger obviously does not seem to check for actual size of memory blocks that a pointer points to but to the theoretical size of the memory block that a pointer has as is infered from the declaration.

Real runtime checks would mean that LabWindows/CVI would need to maintain a complete management structure for every allocated pointer and that would be a serious resource and performance issue.