malloc behaving strangely

[lotrgandalf]

I am getting unpredictable behaviour from malloc(). Here is the code fragment:

float **t;

t=(float **)malloc(sizeof(float *)*A);

perror("\nError status 1:");

for(i=0;i<600;i++)
	{
		t[i]=malloc(sizeof(float)*B);
	}

perror("\nError Status 2:");

The objective here is to have a dynamic 2D float type array. For testing purposes though, I have hard coded the values of variables:
A=60
B=600

The code compiles without any problems. The code runs only till error status 1 when I choose the option start without debugging. However, when the code is executed in Visual Studio in debug mode it starts giving the following debug error at around i=63 and for all subsequent values of i in the loop.

"First-chance exception at 0x77526fcf in abc.exe: 0xC0000005: Access violation reading location 0x00000000."

The output from perror statements is like this:

Error Status 1: No error
Error Status 2: Not enough space

I tried putting additional malloc test statements after the loop to see if I was out of memory. Additional malloc statements after the loop are also giving the same first-chance exception, violation error.

Strangely, it compiles and works perfectly in Linux.

Is this happening because I have run out of contiguous memory in Windows?

Any help is thoroughly appreciated.

[Ancient Dragon]

The value of A is 60, yet you have a loop that assumes its 600. Change that loop like this: for(i=0;i<A;i++)

[lotrgandalf]

The value of A is 60, yet you have a loop that assumes its 600. Change that loop like this: for(i=0;i<A;i++)

Thanks a lot. Stupid overlooked logical fallacy on my part.

But howcome this code works perfectly fine in Linux?

It even worked fine with Cygwin in windows.

[lotrgandalf]

Thanks, Ancient Dragon. +1 Rep.

[Salem]

> But howcome this code works perfectly fine in Linux?
Pure dumb luck - that's all.
In another programming scenario, it would be Linux crashing and windows working as expected.

To gain some measure of confidence, you need to use additional tools.
Eg. valgrind ./myprog or gcc -o myprog prog.c -lefence ./myprog Both of these will run your code with additional memory checks, and cause a crash (even better if you're in the debugger at the time - showing you where).

[lotrgandalf]

Thanks. Problem solved.

[tcstom]

But howcome this code works perfectly fine in Linux?.

From my recent experimentation with Malloc() I have found that, while there is still free memory after the allocated space, you can keep adding values to the array. This is very dangerous because unallocated memory could be overwritten at any time.

[lotrgandalf]

From my recent experimentation with Malloc() I have found that, while there is still free memory after the allocated space, you can keep adding values to the array. This is very dangerous because unallocated memory could be overwritten at any time.

Additionally very deceptive as well as it lulls the programmer into a feeling of seeming correctness.