Back to General and Gameplay Programming

very strange bug (when runing c basic arrays code)

General and Gameplay Programming Programming

Started by fir June 30, 2014 11:55 AM

39 comments, last by Washu 9 years, 10 months ago

fir

-460

Author

June 30, 2014 11:55 AM

I was testing such very simple code


float modelRight_x = 1.1;
float modelRight_y = 1.2;
float modelRight_z = 1.3;
 
float modelUp_x = 1.1;
float modelUp_y = 1.2;
float modelUp_z = 1.3;
 
float modelDir_x = 1.1;
float modelDir_y = 1.2;
float modelDir_z = 1.3;
 
 
 float normal_x[100*1000];
 float normal_y[100*1000];
 float normal_z[100*1000];
 
 float n_x[100*1000];
 float n_y[100*1000];
 float n_z[100*1000];
 
 
 
void matrix_mul_float()
{
  for(int i=0; i<100*1000; i++)
  {
 
    normal_x[i] = n_x[i]*modelRight_x + n_y[i]*modelRight_y + n_z[i]*modelRight_z;
    normal_y[i] = n_x[i]*modelUp_x    + n_y[i]*modelUp_y    + n_z[i]*modelUp_z;
 //third line ->
    normal_z[i] = n_x[i]*modelDir_x   + n_y[i]*modelDir_y   + n_z[i]*modelDir_z;
 
   }
 
  return;
 
}

(dam those forum bug eated text again)

I got runtime crash on the third line , when comment this line its ok, when xchange it with normal_x = ... line it crashes on those x third line then, it also works when changing

normal_z[i/2] = n_x*modelDir_x + n_y*modelDir_y + n_z*modelDir_z;

very strange imo

normal_z[i/1*1] = n_x*modelDir_x + n_y*modelDir_y + n_z*modelDir_z;

crashes

normal_z[i/2*2] = n_x*modelDir_x + n_y*modelDir_y + n_z*modelDir_z;

not crashes

compile options

c:\mingw\bin\g++ -O3 -Ofast -w -c tests.c -funsafe-math-optimizations -mrecip -ffast-math -fno-rtti -fno-exceptions -march=pentium4 -mtune=generic -mfpmath=both

gcc 4.7.1

is this compiler bug?

Bacterius

13,181

June 30, 2014 12:15 PM

Check that your loop limit isn't overflowing (the int type is only technically guaranteed to hold values from -32768 to +32767, and you did say you were using 32-bit XP in a previous thread). Set compiler warnings to maximum. Print the loop counter every iteration. Run through the code with a debugger and see which iteration fails. Is the bug consistent, does it always crash at the same place? If it sometimes succeeds, does it print the right answer or just garbage? What happens if you decrease the number of iterations? You know, the usual stuff. There's nothing wrong that I can spot with the code except the potential for overflow, and, indeed, it works just fine for me.

By the way, there is a difference between "doesn't crash" and "prints the right answer" - differentiating the two in your diagnostics usually helps. And also, please try to avoid tagging your thread "C language" when you are really compiling with a C++ compiler. The two languages are different and go by (often subtly) different rules - you will get into trouble eventually thinking they are interchangeable. Make up your mind on a language, be it C, C++, or C with classes, but please don't say you are using one language and then compile your code as another, that's just misleading for everyone involved.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

slicer4ever

6,773

June 30, 2014 12:17 PM

integer math:

5/1*1 = 5;

5/2*2 = 4; 5/2 = 2.5, the decimal is dropped with an integer, so you get 2*2 = 4.

re-check your allocation sizes, as the code you've posted shoudn't be crashing with those allocations.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

fir

-460

Author

June 30, 2014 12:24 PM

Think it is compiler bug - also vanishes (not crashes) when turning "-O3 -Ofast " into "-O2"

slicer4ever

6,773

June 30, 2014 12:31 PM

the fact that changing compiler settings "fixes" this bug likely indicates you've corrupted memory somewhere, and this is just where it's actually crashing.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

fir

-460

Author

June 30, 2014 12:45 PM

the fact that changing compiler settings "fixes" this bug likely indicates you've corrupted memory somewhere, and this is just where it's actually crashing.

byt this is just multiplication and addition code should work regardless of ram contents - what could be spoiled ?

i got also crashes on such sse intrinsics code


 
void matrix_mul_sse()
{
 
   __m128 mRx = _mm_load_ps((const float*) &modelRight_4x);
   __m128 mRy = _mm_load_ps((const float*) &modelRight_4y);
   __m128 mRz = _mm_load_ps((const float*) &modelRight_4z);
                                          
   __m128 mUx = _mm_load_ps((const float*) &modelUp_4x);
   __m128 mUy = _mm_load_ps((const float*) &modelUp_4y);
   __m128 mUz = _mm_load_ps((const float*) &modelUp_4z);
                                          
   __m128 mDx = _mm_load_ps((const float*) &modelDir_4x);
   __m128 mDy = _mm_load_ps((const float*) &modelDir_4y);
   __m128 mDz = _mm_load_ps((const float*) &modelDir_4z);
 
  for(int i=0; i<100*1000; i+=4)
  {
 
   __m128 nx = _mm_load_ps( &n_x[i]);
   __m128 ny = _mm_load_ps( &n_y[i]);
   __m128 nz = _mm_load_ps( &n_z[i]);
 
   __m128 normalx = _mm_add_ps(_mm_add_ps(_mm_mul_ps(nx,mRx), _mm_mul_ps(ny,mRy)), _mm_mul_ps(nz,mRz));
   __m128 normaly = _mm_add_ps(_mm_add_ps(_mm_mul_ps(nx,mUx), _mm_mul_ps(ny,mUy)), _mm_mul_ps(nz,mUz));
   __m128 normalz = _mm_add_ps(_mm_add_ps(_mm_mul_ps(nx,mDx), _mm_mul_ps(ny,mDy)), _mm_mul_ps(nz,mDz));
 
    _mm_store_ps(  &normal_x[i], normalx);
//    _mm_store_ps(  &normal_y[i], normaly);
//    _mm_store_ps(  &normal_z[i], normalz);
 
 }
 
}

this not crashes but crashes when uncomment one of the commented lines

(as to this code i cannot be sure if this is ok as im very new to sse but also a bit strange) - [this crashes even when i got only -O2, not tested other cases]

Zaoshi Kaba

8,470

June 30, 2014 12:51 PM

100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.

Brother Bob

10,350

June 30, 2014 01:01 PM

100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.

Assuming he didn't butcher the code completely when copying it, the arrays are defined at file scope and are not stack allocated. May still be a good idea to allocate them dynamically rather than statically though.

alvaro

21,604

June 30, 2014 01:14 PM

100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.

It looks like those arrays are global variables, and in that case this should be fine.

I suggest trying to simplify the program (ideally until it's just that function and a main() that does enough to call it), removing everything you can until you have a program that wouldn't show the problem if you removed anything from it. If that's the case, post the complete minimal program so we can try to reproduce the problem ourselves. But there is a good chance you'll find the problem yourself in the process of making the minimal program.

Tribad

981

June 30, 2014 02:01 PM

Allways compile -Wall and make sure you get no warnings. Warnings may differe with optimization levels.

very strange bug (when runing c basic arrays code)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

very strange bug (when runing c basic arrays code)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines