# Program runs fine, then crashes 5% of the time

• 01-30-2011
mat1z
Program runs fine, then crashes 5% of the time
Hi folks,
I'm writing a small simulation of bouncing hard spheres using the Metropolis algorithm. Now my problem is that the program runs fine almost always, also when I vary certain parameters. However, every 20th or so time I run the program it crashes after completion. I have something like 'cout << "Done.";' at the end, and even when the program crashes, this last line is still displayed. I don't even know where to begin looking for bugs since I cannot reliably reproduce the crash.

I'm working on an Acer notebook, Win7 with an i7 720, 4GB RAM.

Now I think I have narrowed the problem down to the following lines (describing a collision check between the spheres after one of them has been moved - if they overlap after the move, the boolean variable overlap prohibits this move):

Code:

```   for (int j=0;j<N;j++)     {          if (j==n) continue;         if (dist(posbuff,0,pos,3*j)<=d) {overlap=true;Nacc-=1;break;}         //else overlap=false;     }     if (overlap==false) {buff2pos(n);} cout << "\n" <<  Nacc << endl;```
with the definitions:
Code:

```float *pos,posbuff[3]; pos=(float *) malloc(3*N*sizeof(float)); void pos2buff(int n) {posbuff[0]=pos[3*n];posbuff[1]=pos[3*n+1];posbuff[2]=pos[3*n+2];} void buff2pos(int n) {pos[3*n]=posbuff[0];pos[3*n+1]=posbuff[1];pos[3*n+2]=posbuff[2];} float dist(float* a,int i,float* b,int j) {return sqrt((a[i]-b[j])*(a[i]-b[j]) + (a[i+1]-b[j+1])*(a[i+1]-b[j+1]) + (a[i+2]-b[j+2])*(a[i+2]-b[j+2])) ;}```
"n" in this case is the sphere that is being moved and hence is left out in the comparison. pos2buff and buff2pos just swap between a dummy variable, dist measures the distance between two spheres. Nacc counts the number of accepted moves.

I hope the above code suffices because the actual program is about 100 lines without much dangerous stuff (I believe).

Hope someone can help me here, or point me in a certain direction. The program is eventually supposed to run for hours, so a crash at the very end is not exactly what I'm looking for... ;)

Matti

PS: Please show mercy on me - I'm still a beginner.
• 01-30-2011
nimitzhunter
Too little code to tell. Potential problems are:
1. Global variables are altered unintentionally. Try passing them as formal argument into your functions.
2. No range checking for your arrays. Make sure 3*n, i and j are inside the range of your array.
• 01-30-2011
mat1z
2. Ranges should be ok. Otherwise, I would rather expect a seg fault or similar, but not a crash that seems to happen randomly? I might be wrong, though.

1. Not sure what you exactly you mean by that, but I take global variables as arguments only.

EDIT: Indeed, I had declared n as a global variable but changed it at runtime. It seems to work now, at least 50 times without a crash.

My question now is: why does this happen? Is there a logical explanation other than that "you can't do it that way."?

Anyway, thank you very much! Problem seems to be fixed! :)
• 01-30-2011
nimitzhunter
Seg fault is not gauranteed for out of range. The behavior is actually undefined. So anything goes for out of range. This may be the cause of more random crashes than global variable. They are hard to catch because there won't be any compiling errors.
Your case was a classic example of how global variables are dangerous. They are a one size fit all approach. Once you alter it, you effectively change the behavior of you entire program. Use #define n or const global variable instead.
• 01-30-2011
cyberfish
Quote:

2. Ranges should be ok. Otherwise, I would rather expect a seg fault or similar, but not a crash that seems to happen randomly? I might be wrong, though.
Actually, in reality, if you overrun an array by a relatively small amount, your code probably won't crash, most of the time, since unless the array is at the beginning of end of your program's memory, the address you corrupt will still be your program's memory (for other variables, etc).
• 01-30-2011
mat1z
Thanks, both of you. Lesson learnt.