I'm having a problem with values read in from a file and assigned to a vector using push_back are not updating. After the values have been assigned, the vector returns zero for all of its values for a fixed time after assignment. The behavior is consistent, and I do not understand why it is happening.

Sorry if the code is a bit ugly, I have been throwing print statements in everywhere to try and debug.

All of the print statements indicate that the value of all of the pedestal entries are 0 for about the first 75000 calls, at which point they begin to reflect the values read in from the file. However, the print statements also verify that the values are being read in at the beginning of the first call. I can't explain the delay between assignment of values using "push_back" in initPedestals and the return of the values using "at" in process. (or the direct access operator in the print statement in initPedestals either!)

If anyone can see what the problem is, or give me an idea of what might be causing this so I can track it down in the rest of my code, it would be much appreciated!

I would still appreciate an explanation of why this is necessary and any advice on how I could implement this better.

Thanks!

07-31-2009

laserlight

Quote:

Originally Posted by cowboyjo

Sorry if the code is a bit ugly, I have been throwing print statements in everywhere to try and debug.

Consider using a debugger instead.

Quote:

Originally Posted by cowboyjo

All of the print statements indicate that the value of all of the pedestal entries are 0 for about the first 75000 calls, at which point they begin to reflect the values read in from the file. However, the print statements also verify that the values are being read in at the beginning of the first call.

Considering that you print nothing from the else branch of the outer if statement in initPedestals, perhaps that is merely due to an omission in your print statement placement. Using a debugger, observe if the flow of control reaches that else branch, e.g., by placing at least one breakpoint there.

07-31-2009

cowboyjo

well, seems I was too optimistic about the above fix. The code works as is, but if i take out the various print statements and revert the control statements (basically undoing all the damage done during the debug process) the problem returns.

All of the print statements indicate that the value of all of the pedestal entries are 0 for about the first 75000 calls, at which point they begin to reflect the values read in from the file.

Let me guess. You sized your vector (by declaring whatever(75000) or something similar) when you declared it, putting 75000 copies of 0 in your vector, and then you're using push_back to add things to the back of your vector, after those 75000 zeroes.

How'd I do?

07-31-2009

cowboyjo

Quote:

Let me guess. You sized your vector (by declaring whatever(75000) or something similar) when you declared it, putting 75000 copies of 0 in your vector, and then you're using push_back to add things to the back of your vector, after those 75000 zeroes.

How'd I do?

It doesn't seem to be that simple. I do not have a vector of length 75000 plus, I merely access the elements of a 128 deep vector 75000 times and get a zero, and then magically get the correct value on the 75001 time (it's actually 76495, but that's irrelevant).

I've confirmed the values are only read in and assigned at the beginning of the first call, that control never enters the final else statement in initPedestals, and no further calls to initPedestals are made.

Also, using swap to fill the vectors got rid of the problem temporarily, but it resurfaced when I changed the if statement at the top of process to "if (md.pedestals().empty())"

07-31-2009

laserlight

I suggest that you learn how to use a debugger right now. Then, if you are still unable to debug successfully, post the smallest and simplest compilable program that demonstrates the problem. You should provide sample input and the corresponding actual and expected output.

07-31-2009

cowboyjo

I'll post more info and a simplified example if I can recreate the problem within a simpler context, but until then I would still appreciate any insight into this problem. Has any one ever experienced anything like this?

07-31-2009

tabstop

Quote:

Originally Posted by cowboyjo

I'll post more info and a simplified example if I can recreate the problem within a simpler context, but until then I would still appreciate any insight into this problem. Has any one ever experienced anything like this?

Well, to be honest, lots of times. And it's always been using push_back when I meant to assign whatever[i] instead (or forgetting about a bunch of zeroes in the front, etc.). That's strongly indicated by the fact that swap worked, since temp1 and temp2 were blank when you started, so you're not adding to the back of a lot of zeroes. (I mean, if you're calling this routine hundreds of times (if not 75000 times), your pedestal vector must get freakishly large.) I suppose you could check what pedestals().size() is when you start, and if it's not zero then you've got extra stuff. It sounds like your file is opening.

07-31-2009

cowboyjo

Thanks for your replies tabstop, I did find where the vector is being filled with zeros in a different part of the code.

What threw me was the fact that the correct values eventually did appear. Just for clarification, I'm only filling the pedestals vector with 128 values and then calling pedestals.at(0..127) to retrieve those values. Thus, I would have expected all accesses to pedestals to return 0, and can still not explain why the nonzero values suddenly appeared after so many calls. Perhaps there is still another bug to be tracked down...

08-07-2009

cowboyjo

I did get the time to pick up the basics of gdb this week, and it has already proved a worthwhile investment.

Just wanted to let you know that I did take your advice, laserlight, it just wasn't feasible in the time frame I had to fix the above bug.