When is it necessary to start initializing variables to the heap?

I've read many conversations here on stack and heap and I think I might have a problem related to that. I have a program about 700 lines and for some odd reason when I open up a for loop the program crashes every time. There is nothing inside the for loop except for a conditional to break the loop when I press enter. I don't know if this makes a difference but I am working with SDL using codeblocks. Is it possible that the "stack" is filled up? Thanks for any response.
Post the code.
I tweaked the code a lot since I first posted but this is pretty much the same. Program crashes once it goes into the for loop. Note: I tested it by blitting a series of about one hundred pics back to back and the loop works fine??... until it gets to the last pic and just crashes. It's like the loop needs to have something to do for the program not to crash.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
///---the play screen for 1 player---
                else if(playScreenOnePlayer==true)
                {
                        SDL_BlitSurface(mainGameBackGround, NULL, screen, NULL);///blit background picture
                        
                        if[keystates[SDLK_ESCAPE])///If user presses escape, enter the pause menu
                        {
                            for(;;)
                            {
                                if(keystates[SDLK_RETURN] && pauseSelectionMenu == 1)///if user presses enter when on the first option, return back to game
                                {
                                    break;
                                }
                            }
                        }
                }


Don't know if it matters but this is not in the main
Last edited on
This may not be the answer. But my first thought is that the for (;;) loop is a cpu-hungry way of pausing the program.

I'd normally put something like Sleep(100) in there so that it is still checking the keyboard, but is also releasing the processor so the operating system can attend to other tasks. Or maybe SDL_Delay instead of sleep.
There's likely memory corruption going on. When you attempt to read from or write to memory you don't own, you invalidate the state of the program. The program may then crash at an essentially random point in the future (or possibly not at all) and arbitrarily far from where the actual bug is.
You should check your code. Look for buffer overflows, reads from uninitialized variables, deletion of invalid pointers, and the like. If you can, run the program through Valgrind.
@ Chervil

I ended up using sdl_delay and even my timer functions but it still did not work. I eventually restructured everything so I did not have to use a loop. Also, would it be less memory intensive to just insert a conditional as a parameter instead of three empty parameters? Thanks!

@ helios

Just did a quick search on Valgrind. Will try it out. Is this a program programmers use in the industry. Just curious.
Last edited on
It is an important part of the testing procedures of some popular programs, although I can't recall any examples, at the moment.
I think my suggestion was probably a red herring in this instance. It was cpu time that the loop used, not memory. I guess the problem is elsewhere.
Well thanks a lot. Program works fine.
Rookie mistake...finally found the problem. The above code can work

Just for future reference if anybody ever comes across this rookie mistake of a problem. In my limited knowledge, SDL needs to be able to poll for events if your program is going to continually loop so the reason the code above did not work was because I did not have this.....

1
2
3
4
5
6
7
if(SDL_PollEvent(&event))
{
        if(event.type == SDL_QUIT)
        {
            return 0;
        }
}


Works just fine now. This wouldn't work with a delay...
It's important to understand the difference between a crash, when the program terminates unexpectedly due to an error, and a hang, when the program enters an infinite loop and never terminates.
Yet another kind of failure is the deadlock, which happens when two mutually dependent parts of the program are simultaneously waiting for results from the other. It's similar to the hang in that the program never terminates, but different in that it only arises in threaded code. A deadlock also uses no CPU time, unlike an infinite loop.
Topic archived. No new replies allowed.