Thread: Variable has bizarre and unexpected value

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.

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);

}

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

>> 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.