Variable changes in between functions (out of bounds?)

[PaulM.]

I tried to strip down the function Forces(), and I noticed some weird things.
- If I turn off the first part of the function, the check-up part before the loop, the problem moves to the next variable that is within the for-loop (rx).
- If I turn off the check-up AND I turn off the last 4 lines or the 4 lines before those, everything works well.
- If only the check-up or the lines at the end of the loop are turned off, but the other block isn't, it does not work.

I hope you understand what I mean. I've added some comments with the linenumbers in the source. The stripped down version is attached.

[frankie]

Maybe it is not a good new for you, but maybe your assignement is not fully complete...
In function Forces if I change the line

Code: [Select]

Force Fc[c_n+1]; // Forces due to impact
to

Code: [Select]

Force Fc[c_n+2]; // Forces due to impact

It doesn't crash.
Seems that the problem is simply a wrong array access, you are writing beyond the bounds, overwriting stack variables.
Please check and report so we close the issue. 

[PaulM.]

That indeed solved the problem. An honest but stupid mistake

[frankie]

I hope that you are studying physics and not computer science...... 
It's a joke
Anyway is always a bad idea to create large local variables (because they eat processor stack that generally is a limited resource), creating arrays is even worst because indexing problems can create what happened.

[CommonTater]

So... forgive my confusion... but how does setting optimizations to none fix an array bounds error? 

In all respect to my friends here, I'm not entirely sure the solution is as simple as making a bigger array.  If it was merely an array bounds overrun, changing the compiler settings should not have had any effect and I should have been wrong in my first suggestion. 

I'm guessing the +2 suggested simply pushed the next variable back out of harms way, and the overwritten memory location remained unused by the OP's code, hiding the problem rather than fixing it.

I do agree that he probably should have used malloc to create the arrays...

[frankie]

I didn't said that making the array bigger solved the problem, but that the test I made, enlarging the array, demonstrates that there was an array bounds problem, and asked him to check the program correctness (I cannot waste time studying his whole program). But from the answer seems that he really made an error on array dimensioning.
With optimization none all variables are layout in memory while with optimizations on many are allocated in registers, memory layout could be different more dead space can exist in data structures.
In the first case maybe the overwriting involved different variables that weren't used after, while with optimization the compiler kept almost only the big arrays on the stack so they were overwrited (the bloated counter is on the calling function stack, the local value seems correct). The casualties are so frequent that some programs can work for years and the bug remains hidden (there are many cases with M$).
To exactly understand what happened you should trace the assembler and check memory writes, unfortunately with large arrays and so many data manipulation to do it would really be a nightmare 

[CommonTater]

Hi Frankie

I agree there may be to concomittant issues here...  but all that means is there's more than one problem.

[PaulM.]

It was an array issue. Forces had c_n+1 elements, which is 96+1 = 97 in this case. That means indexes 0-96 can be accessed. I tried to acces index c_n+1 = 97, and that index is out of bound.

I hope that you are studying physics and not computer science...... 
It's a joke
Anyway is always a bad idea to create large local variables (because they eat processor stack that generally is a limited resource), creating arrays is even worst because indexing problems can create what happened.

I study Mechanical Engineering. Normally we do numerical modelling with Matlab, but for this project we had to learn C to understand programming a little bit. We've ony been doing this for 6 weeks (that's why I posted in the Beginners section).

[CommonTater]

We've ony been doing this for 6 weeks (that's why I posted in the Beginners section).

My compliments!  For someone a very few weeks into this, you've done really well.  From your source code I would have pegged you at the 1 year level, or beyond...

Even though it was an array access issue that still doesn't explain how turning off the optimizer appeared to solve the problem... Oh well, we may never have the answer to that one...

[frankie]

Yes Paul good job!
Matlab models are in C and the free compiler that come with it is LCC-Win32, so this work on Verlet integration will be very usefull to bet understand modeling in Matlab.
Tater the issue with the nooptimization is clear. Of course if you would like to understand the details you have to follow in assembler the whole process to see where the code overwrites the variables, how overwrite them and which of them are overwrited.

[CommonTater]

Frankie...
As you know, my knowledge of ASM is just a tad lacking.  I know how to do a few little things; like the garbage collector experiment in user contributions, but to sit down and analyse ASM listings I've not written is a bit beyond my skillset. 

Sooooo... I'll trust you on this one

Still... until that bug is fixed, I think I'll continue building my projects with optimizations off ...
 

[CommonTater]

Paul...
Taking a last look at your code...
 
There is one little change I'd make ... in read_data() ... if the data file doesn't open you need to exit the program completely since that is a fatal error for the rest of the code.  There are two ways to engineer that... either change the return 0 in the "did it open" test to exit(GetLastError())  -- or -- change the final return 0 in the function to a return 1 and test the returned value in main.c, exiting from there if you get 0 back.  What you can't do is let your program go crashing along if that file doesn't open.
 
This might not seem like a big deal in what amounts to a class assignment, but it's never too early to form good habits regarding safe code.  I would suggest that when you write anything that relies upon external forces --data files, dlls, user input, ports, etc.-- you should always spend a couple of minutes asking yourself "What happens if the file isn't there?", "...the port isn't connected?", etc.  And try to deal with as much of it as you can before causing an actual disaster. 
 
You will see that I have a thread running in the Expert forum where I'm seeking advice on the best way to deal with unknown values from GetLastError() ...  So you should expect an ongoing struggle.
 

[PaulM.]

Thanks for the compliments. I hope the tutors will agree with you; they also judge heavily on the organisation and readibility of the code (because that is the main learning objective of this course). I have to admit that I've been working with Matlab for three years now, and before I went to study at the university I had scripted some PHP in my sparetime for one and a half years; that gave me a nice headstart on my fellow students.

CommonTater, you're absolutely right about the safety check. When the code stopped working I gradually started adding extra failure notifications - some of the are already coded in the project I uploaded earlier. But the external datafile is indeed crucial for the code to work. I've changed the code so the program stops immediately if there's an error in reading that file.

Again, thanks for all the help! I appreciate it.

[CommonTater]

Hey ... no worries!

Good luck on the course!

[frankie]

Tater I meant that it's a huge job to trace puntually each memory read and write. And it's not worth of because it is well known, it relates also to buffer overflow techniques used by virus. If you get a local variable address (tipically a char buffer) and start to fill stack with the address of the virus code there is avery high probability that you will overwrite return address (that lays on the same stack) with the maliciust code address. The result is that when your function finish will pick-up from the stack the virus address instead of the return address. What happen after is sadly famous 
In my years of system code programming, more than 20, this is engraved in my mind.
So at the end there is no bug at all in generated code. Anyway not using optimization with this compiler is like to drive a Ferrari using only the first gear   
Paul maybe readability is not the best, I suggest to add more comments, and some constructs shows PHP habits, but in general I confirm my opinion that your code is good enough.