program quits unexpected

Let's say that you defined this:

Code:

---

int CP_count[5]  = 0 ;
int act = 0 ;

---

As you can see visually, act follows CP_count.
If the compiler happens to place act immediately following CP_count in the stack, and if you coded

Code:

---

CP_count[0] = 0 ;
CP_count[1] = 1 ;
CP_count[2] = 2 ;
CP_count[3] = 3 ;
CP_count[4] = 4 ;
CP_count[5] = 5 ;

---

then because 5 is out of range for the array, then the variable act would receive the value. This is what would get saved:

Code:

---

CP_count[0] would be 0
CP_count[1] would be 1
CP_count[2] would be 2
CP_count[3] would be 3
CP_count[4] would be 4
act would be 5

---

The same situation could also occur if both CP_count and int were malloced, as they could be adjacent in storage.

This is a very simple example, and overlays can be much more complex than this.

So you're saying that the range of CP_count is too small and

Code:

---

CP_count[CP_nr] = 1

---

then changes the next thing in stack (probably). This seems a logical explanation, but shouldn't it be more logical that act is changed in 1 instead of 0 (because that piece of code is writing "1".
(I will now try to run the program with larger CP_count...)

Quote:

---

Originally Posted by skelesp

So you're saying that the range of CP_count is too small and

Code:

---

CP_count[CP_nr] = 1

---

then changes the next thing in stack (probably). This seems a logical explanation, but shouldn't it be more logical that act is changed in 1 instead of 0 (because that piece of code is writing "1".
(I will now try to run the program with larger CP_count...)

---

What type of data is act, and what type of data is CP_count?

If act is a short or char data type, and CP_count is an int or long, then you may write zeros to the act.

--
Mats

Quote:

---

Originally Posted by skelesp

(I will now try to run the program with larger CP_count...)

---

That's a TERRIBLE way to fix a problem - you are possibly masking the error, or just moving it somewhere else. And, it might not even be that CP_count is the issue, like I said above, overlays can be much more complex than my example. People who code with this mentality end up getting fired.

You can determine if CP_count and act are adjacent in storage by printing out their addresses.

You can also add an error checking function to see if CP_nr is out of range for the maximum allowed value.

Indeed, CP_count is a double and act is an integer. So, 1 will probably become zero in this conversion.

I have increased the range of CP_count, and act does not change to 0 anymore!! Thanks for this solution. Unfortunately, my program still stops during one of the 5 files. But I'm happy, this strange error has been solved. Now I can look for other variables being overwritten by others :)

Thanks for the help guys!!

Quote:

---

Originally Posted by Dino

That's a TERRIBLE way to fix a problem - you are possibly masking the error, or just moving it somewhere else. And, it might not even be that CP_count is the issue, like I said above, overlays can be much more complex than my example. People who code with this mentality end up getting fired.

You can determine if CP_count and act are adjacent in storage by printing out their addresses.

You can also add an error checking function to see if CP_nr is out of range for the maximum allowed value.

---

Ok, you're probably very right, because I still have an error in my program :)

Can you explain some more what you just said?

How can I print the addresses of variables? And which error checking function can I add to check whether CP_nr is out of range?

For a routine, you could:

Code:

---

#define MAX_CP_nr = 100    ( or whatever it is )
..

int check_CP_nr(int value) {
  if (value > MAX_CP_nr) { printf("CP_nr out of range!! value = %d", value) ; exit(-1) ; }
  return 1 ;  // value is OK
}
...
...
...
if (check_CP_nr(CP_nr)) CP_count[CP_nr] = 1 ;  // as an example

---

For printing addresses,

Code:

---

printf("act is at address %p\n", &act) ;

---

I have implemented the error function and printed the addresses of act and CP_count. Result:
CP_nr out of range!! value = 101
act: 0058A200 CP_count: 00589EE0

So, one of the problems certainly is that CP_nr is going out of range (The max range of CP_count was in fact 100, so CP_nr couldn't be more than 100). I tried using

Code:

---

memset((void*)&CP_nr, 0, sizeof(int)*MAXACT);

---

at the end of each iteration of a file (I don't exactly know why :) but it helped me several times before). Perhaps this is again totally wrong?! Because after I did this, another variable was changed unexpectedly, causing the program to crash.

Dino, what is the best way to debug my program, knowing that CP_nr is causing some trouble somewhere... ?

There is actually 800 bytes (200 integers) between cp_count and act, so if it's an int, you'd be overwriting a lot more than just the cp_count. Is there something else in between?

--
Mats

In between what? I declare all my global variables in one headerfile (I know this is probably not the best way to do this, but it was the easiest for me when I started this program) Perhaps all the declarations between act and CP_count are in those 800 bytes??

Otherwise, how can I debug my program in the most efficient/easy way to discover where CP_count overwrite things...

1) Implement the same style of bounds checking for your other arrays.

2) If you are constructing or reading in any strings, you can add a strlen() test when finished to see if your string is longer than the character array that houses it. (Really, the same as the above test.)

C is notoriously susceptible to both of the above conditions.

If you are using MSVC, perhaps you can build in debug mode and that will tell you if you are corrupting the stack at runtime. Do you use the "const" attribute for all variables and function declarations it would apply to? This might have the affect (depending on your compiler) to put these values in read-only memory and thus, removing these values from the equation.

What is different about these 5 (or now 1) files? Much larger? Smaller? Longer than usual strings? Binary data in what is expected to be a text file? Lines endings different?

Quote:

---

Originally Posted by Dino

What is different about these 5 (or now 1) files? Much larger? Smaller? Longer than usual strings? Binary data in what is expected to be a text file? Lines endings different?

---

Well, actually there are only little differences between the 900 files. They are all written in the same format and contain only numbers.
I don't know whether this will be clear, but each file describes a (project)network with 30 activities (which all have different durations)+2 dummy activities (=32 activities in total).
File 1 describes a highly serial network (with lots of activities happening after each other), file 900 describes a highly parallel network (with lots of activities happening at the same time). The files in between are a combination of parallel and serial activities. So, the files themself are all the same size, have the same content, etc...

Tomorrow, I will try to find more array which cause some trouble. Now I know already more what too look for...

PS: 1 extra question (for now): when is it advisable to use memset? Because I'm using it to clear some variables at the end of my program (once got this advise from another forum), but I'm starting to thinking I shouldn't do this.

Quote:

---

Originally Posted by matsp

There is actually 800 bytes (200 integers) between cp_count and act, so if it's an int, you'd be overwriting a lot more than just the cp_count. Is there something else in between?

---

Is there a way to find out which variables or values are on those addresses between act and CP_count?

If they are global and in the same source-file, then they are in memory in the order they are declared.
It's harder if they come from different sources or local to functions.
- Local to functions is in the call order (last call at the lowest address), and there will be "stuffing" inbetween variables (return address, frame-pointer, saved registers).
- Globals in different files is PROBABLY in the order they are linked in - but there is no guarantee of that. You'd have to print addresses of the first variable in each source file.

--
Mats

skelesp, I think it's time you invested some of your time in learning an interactive debugger.