Bizarre bug-- for loop stalling

[declan]

Hi guys. I have a very strange problem. In my program, I enter a number of particles for the program to work on, and a number of steps for it to go through. The more particles, the longer it will have to work. The main core of my program is essentially:

//User selected int nstep up here.
for(int istep=1;istep<nstep;istep++){

    cout << "We're at the top of the loop! << endl;

    someFn();

    anotherFn();

    etcFun();

    //and so on.

    cout << "We have done " << istep << " out of " << nstep << endl;

} 

The functions called repeatedly from inside the for loop are pretty resource heavy. However, they've always worked in the past. I recently made a few changes to them, and now I'm getting the most bizarre bug: It will run for some number of iterations (the number seems to depend on the number of particles, but not directly in any way. Not proportionally, not inversely proportional), then just stop. It doesn't crash, just pauses indefinitely until I hit Ctrl+C to kill it.

Now here's the weird thing: It is stalling between the "We have done x out of y" print statement, and the print statement at the top of the loop! There is nothing in between those.

Now, as a last ditch effort I tried commenting out the functions one by one and letting the program run. For most of them, it didn't make a difference, it still stalled. But for the usual troublemaker, let's say it was someFn() in this case, when I commented it out, things work fine (minus it not doing its job). The loop works correctly. But this doesn't make sense! It's stalling in between the print statements! Furthermore, I have at the VERY beginning and VERY end of someFn() two similar print statements (cout << "Entering someFn()" << endl; and cout << "Leaving someFn()" << endl;), and there's no case of it entering and not leaving.

There is no multithreading or anything fancy going on. What could it be?

Thanks!

[Disch]

Smells like heap corruption.

You're probably stepping out of bounds in an array somewhere or dereferencing a bad pointer.

[declan]

But how would that explain this? It's still just managing to hang in between those two print statements.

[filipe]

Step through it with the debugger.

[guestgulkan]

What do you mean when you say 'resource heavy'

[Disch]

But how would that explain this? It's still just managing to hang in between those two print statements.

Heap corruption can cause just about anything.

The program itself (the exe) exists on the heap, so heap corruption might result in the actual program getting scrambled during runtime.

[helios]

Uh... Code is in read-only memory, next to other static data such as string literals, precisely to prevent that sort of thing from happening.

I would blame some critical loop variable getting overwritten. I got a similar bug when fixing an ancient crypt(3) implementation that made assumptions about the relative positions of global arrays and took advantage of it to merge initialization loops by writing past the end of the array. Something like that (that is, a buffer overflow) may be happening here, although I wouldn't rule out plain ol' memory corruption.

[declan]

Step through it with the debugger.

Will do. Reading up on gdb right now.

What do you mean when you say 'resource heavy'

Allocates large blocks of memory for long periods of time. Heavy, frequent calculations. Not as bad as classic molecular dynamics, but still heavy. Read about three dimensional Direct Simulation Monte Carlo if you're interested.

Uh... Code is in read-only memory, next to other static data such as string literals, precisely to prevent that sort of thing from happening.

This is what I would expect...but the variables of the program are in heap memory, right? I don't know much about that.

As for the critical loop variable, look at my sample code. It's exactly like that. It prints out the two relevant loop variables right before it should go to the top and check if they work. I am pretty confused at this point, as the thing I can comment out to make it work doesn't do anything with memory allocation. bleh.

[helios]

the variables of the program are in heap memory, right?

No. Stack.

Try adding something like this at the beginning of the loop:

//#include <cassert>
assert(loop_variable>last_value); //last_value is the value of loop_variable during the last iteration 

If the assert fails at one point, it means someone is overwriting loop_variable. Your debugger may let you set up data breakpoints (a breakpoint that triggers when data at a memory location changes), which you can use to find the exact culprit very quickly.

[declan]

So, I pulled out gdb. Led to me eventually finding the problem. So I fixed it, but it still doesn't actually answer my question.

It was getting caught in an infinite loop. Nothing with heap corruption or anything. A stupid error. But that still doesn't explain why it was printing out (or even getting to) the statement at the end of the loop! I fixed it, but I'm baffled. Anyone have any idea?