Variable has bizarre and unexpected value

I’m not a newbie C programmer (nor an expert), but I’m still puzzled by the following problem: I use the code below (a very simplified version of my code) to declare, assign value to, and print the value of an int variable. I have searched my full C program to ensure that the value of nsteps isn’t being changed anywhere else in the code:

Code:

double myfunc(args){

  int j, nsteps = 200;

    for(j = 0; j = nsteps; j++){
         … 
        printf(“value of j = %d, nsteps = %d.\n”, j, nsteps);
         …
    }
}

The values that print are j = 0 and nsteps = -2147483648. Again, nsteps is used in a couple of other places later in this function, but its value is never changed from 200 anywhere in the code.

Does anyone have a suggestion about what might be causing this nonsensical value to be assigned to nsteps? Thanks in advance for your input.

Could be you are overwriting some part of the function stack by going out of bounds on an unrelated array. Post the real code for the whole function.

Not without you posting something which actually demonstrates the problem.

"Something like this code" doesn't tell us a lot.

for(j = 0; j = nsteps; j++){ // j = 0; j < nsteps perhaps ?

Are you sure that 'the values that print are j = 0 and nsteps = -2147483648'

Ok, you asked for it! I hope this helps; this function is one of around 7 that my full program uses, so... I'm not positive the the source of the problem is necessarily contained within this particular function. But if you see anything problematic in the code below, that would be a good start.

I will also mention that, in the process of trying to debug, I've used print statements and determined that many/most of the variables in the code below presently have values of 0.000 or nan, instead of their expected values. This includes the error values (e1 etc.), the q values, all Stim[ ] values, etc. I'm aware that at least one of my other functions is likely involved in this problem; however, if there is anything that needs to be changed below, that will help.

Code:

double reach(double p[], double *error, double *effort)
{
int i,j,k,n, nsteps, numder, numint;
double t, step, sumeffort, sumerror, ymin;
double q[NDOF], qdot[NDOF], F[NMUS], m[12], Lce[NMUS], Act[NMUS], Stim[NMUS];
double e1, e2, e3, e4, e5; /* calculated error values */
double cputime;
double W = 0.05; /* weight for cost function */
time_t clockstart;
double initact[NMUS] = {0,0,0,0,0,0}; /* initial muscle activation levels */
double return_val; /* cost function return value */
double initq[NDOF] = {0,0};
double initqdot[NDOF] = {0,0};
double initLce[NMUS];
int v, w;

clockstart = clock();

for(n = 0; n < NPAR; n++)
globp[n] = p[n];

copyPtoG(globp, Gp, Gd);


t = 0.0;


/* do the simulation, compute cost function, and write output files */

sumeffort = 0.0; /* initialize effort sum to zero */
sumerror = 0.0; /* initialize error sum to zero */
nsteps = 200; /* simulate for a total of 2.0 sec */
step = 0.010; /* time between samples */


/* simulate one step in the specified reaching task */
for(v = 0; v < NUMTASKS; v++){
for(w = 0; w < NDOF; w++){

initq[w] = initial[v][w];
single_target[w] = target[v][w];


initLce[0] = 99; /* CE starts just slack in each simulation */

initcond(&t, initq, initqdot, initact);


for (j=0; j<nsteps; j++) {

simulate(&t, step);

getq(q);
getqdot(qdot);
getmuscle(F, m);

printf("In reach(): calling user_stim(); j = %d, nsteps = %d.\n", j, nsteps);

user_stim(&t, q, qdot, Stim);

/* add this sample's results to the cost function */
e1 = q[0] - single_target[0];
e2 = q[1] - single_target[1];
e3 = q[2] - single_target[2];
e4 = q[3] - single_target[3];
e5 = q[4] - single_target[4];

sumerror = sumerror + (e1*e1) + (e2*e2) + (e3*e3) + (e4*e4) + (e5*e5);


for(k = 0; k < NMUS; k++)
sumeffort = sumeffort + (Stim[k]*Stim[k]);


} /* end for(j) loop */


} /* end for w loop */

} /* end for v loop */



/* compute cost function: RMS diff between simulation and data, normalized to SD */

*error = sqrt(sumerror/(nsteps*NUMTASKS)/NDOF)*(180/PI);
*effort = sqrt(sumeffort/(nsteps*NUMTASKS)/NMUS);

return_val = (*error + (W*(*effort)));

return sqrt(return_val);

}

hmm, that's weird; I posted my full function in my previous post, but now it seems to have disappeared, and only the function name is visible.

Anyway, an update: I've been able to narrow down where the value of nsteps is changing; I added a print statement at the very beginning of my for( ) loop:

Code:

for (j=0; j<nsteps; j++) {
    printf("in for j loop: j = %d, nsteps = %d.\n", j, nsteps); 

    simulate(&t, step);

    getq(q);  
    getqdot(qdot);
    getmuscle(F, m);

    printf("In reach(): calling user_stim(); j = %d, nsteps = %d.\n", j, nsteps);

    ... 
}

nsteps has the correct value of 200 in the first print statement, and then always changes to the same nonsense value of -2147483648. Is it odd that it always has this same incorrect value? Seems like if it were a stack overwrite, the wrong value would be different each time. ??

Somewhere in simulate(), getq(), getqdot(), getmuscle(), you are writing beyond one of the arrays. Check the value of NMUS. It's odd that nsteps would be affected though. I thought the compiler assigns pretty much consecutive memory locations in the order the variables are defined.

Perhaps you are indexing with negative subscripts so that variables before the arrays are clobbered.

Originally Posted by nonoob

I thought the compiler assigns pretty much consecutive memory locations in the order the variables are defined.

It usually does, but reserves the right to re-order them for efficiency or any other reason it can come up. Point is not to rely on that behaviour.

QuantumPete

>> Somewhere in simulate(), getq(), getqdot(), getmuscle(), you are writing beyond one of the arrays. Check the value of NMUS. It's odd that nsteps would be affected though. I thought the compiler assigns pretty much consecutive memory locations in the order the variables are defined.

>> Perhaps you are indexing with negative subscripts so that variables before the arrays are clobbered.

The value of NMUS is a positive integer; NMUS is a macro.

What bothers me is that the code I'm presently working on is analogous to previous code that I used, and the 4 functions you list above are part of a function library that I didn't write; it is very doubtful that there is a problem with any of these functions.

Any ideas about what might be wrong with *my* code, that would cause these functions to return nonsense values for the arrays that are input as arguments? I have triple-checked that each array I use has the correct dimensions, and there should definitely not be any negative indexing occurring.

always changes to the same nonsense value of -2147483648

You should be able to find out when does it happen?

Code:

 simulate(&t, step);
  // here ?
    getq(q);   // ??
    getqdot(qdot); // maybe here?
    getmuscle(F, m); // ...

Isn't this what a debugger was made for???

Originally Posted by rags_to_riches

Isn't this what a debugger was made for???

of course

>> Isn't this what a debugger was made for???
I know you're right... but it will probably take longer to learn how to use the debugger than I want to spend, and I was just hoping for some insights before I go that route...


>> You should be able to find out when does it happen?
yeah, I've printed out all of the values that get returned from each function; they are a mix of reasonable values and absurd, nonsense strings of hundreds of numbers, as well as inf and NAN. There doesn't appear to be any rhyme or reason about when these nonsense values occur; the 2nd element of the q array might have such a nonsense value, and then e3 has such a value, etc.

Hmm, your question prompted me to inspect this screen output more closely; it appears that the 3rd & 4th elements always appear to be problematic. I'll check into this further...

Code:

/* simulate one step in the specified reaching task */
for(v = 0; v < NUMTASKS; v++){
for(w = 0; w < NDOF; w++){

initq[w] = initial[v][w];
single_target[w] = target[v][w];

That's the first time that variable is referred to, is it global?

Originally Posted by CodeKate

>> Isn't this what a debugger was made for???
I know you're right... but it will probably take longer to learn how to use the debugger than I want to spend, and I was just hoping for some insights before I go that route...

This is not optional CodeKate. You are only going to be creating more and more and more headaches for yourself until you learn. And they will get worse and worse. And then one day you buy the asprin, kind of thing, and are thankful for it.

If you are on *nix/have access to gdb, check this thread:
getting a segfault using pointers
maybe just skip to post #7. Debugging ain't that hard. Your case is somewhat more complicated than that one tho.

>> That's the first time that variable [initial] is referred to, is it global?
Yes, it is. It's one of the new variables I introduced since my last (working) version of this code, so potentially it could be a problem.


>> This is not optional CodeKate. You are only going to be creating more and more and more headaches for yourself until you learn. And they will get worse and worse. And then one day you buy the asprin, kind of thing, and are thankful for it.
I know, I know


>>If you are on *nix/have access to gdb, check this thread:
Thanks, I'll give it a look.