What does this error mean? I wrote a program with recursion, and the number of recursions before I get this error is 354. Are you only allowed to have recursion so deep?
Is there possibly a way to get around this? Recursion has never let me down before, and I found it extremely weird that it just all of a sudden did. Granted, I think 354 recursive calls is a tremendous amount, nonetheless, but I don't understand how else to go about this problem.
My code:
1 2 3 4 5 6 7 8 9 10 11
int iterativeSequence(int number) {
// Number was 1
if (number == 1)
return 1;
// Number was even
elseif ((number % 2) == 0)
return (iterativeSequence(number / 2)) + 1;
// Number was odd
elsereturn (iterativeSequence((3 * number) + 1)) + 1;
}
Everything works just fine. However, somewhere around the 50,000th time that the program calls cvGet2D() the program exits with the message "Process returned -1073741819 (0xC0000005)".
I'd love to be able to get 50,000 recursion, but I come no where close, and I'm not even using objects. I don't believe this is causing memory leaks, but I have no clue, I've never encountered something like this before.
I'm not sure if that is your problem here or not, but yes you can only go so deep in recursion before your stack overflows.
When a function is called, stuff is put on the stack, and only unloaded when the function returns. With recursion a function keeps calling itself without returning, and things keep piling onto the stack.
The stack in action
Because parameters and local variables essentially belong to a function, we really only need to consider what happens on the stack when we call a function. Here is the sequence of steps that takes place when a function is called:
The address of the instruction beyond the function call is pushed onto the stack. This is how the CPU remembers where to go after the function returns.
Room is made on the stack for the function’s return type. This is just a placeholder for now.
The CPU jumps to the function’s code.
The current top of the stack is held in a special pointer called the stack frame. Everything added to the stack after this point is considered “local” to the function.
All function arguments are placed on the stack.
The instructions inside of the function begin executing.
Local variables are pushed onto the stack as they are defined.
When the function terminates, the following steps happen:
The function’s return value is copied into the placeholder that was put on the stack for this purpose.
Everything after the stack frame pointer is popped off. This destroys all local variables and arguments.
The return value is popped off the stack and is assigned as the value of the function. If the value of the function isn’t assigned to anything, no assignment takes place, and the value is lost.
The address of the next instruction to execute is popped off the stack, and the CPU resumes execution at that instruction.
...
In the lesson on the stack and the heap, you learned that every function call causes data to be placed on the call stack. Because the CountDown() function never returns (it just calls CountDown() again), this information is never being popped off the stack! Consequently, at some point, the computer will run out of stack memory, stack overflow will result, and the program will crash or terminate. On the authors machine, this program counted down to -11732 before terminating!
Then what would be a solution to a simple function like I posted above? Do the return statements cause a larger stack than possibly passing a variable by reference to hold the return value? I don't know specifically what I'm doing wrong that is causing the stack overflow. It seems simple to me, write a small function, wait for result. Result crashes program. Now what?
Reading through the stackoverflow link, what I obtained from that is constantly calling a recursive function will eventually give me a stack overflow? If I limit my calls to the function, will that reduce the chances of stack overflowing? Do I need to come up with an algorithim to figure out when to run my function, and when no to?
I never understood what a stack overflow was, nor did I ever have an issue with it unless I typed something incorrectly. I'll have to read through iseeplusplus's comment to see exactly what's going on, and specifically, why stack overflow happens. I understand the term, but not in practice.
Is a stack overflow going to happen at the same time on everyone's machine? Meaning, if I get a stack overflow at my 5,000th call, will someone else on a different OS get the same issue? What if they have the same OS, but different hardware? Is there a way to physically determine when a stack overflow will occur? Or just try to greatly reduce the chances of it happening?
@viliml
That's exactly where mine stopped, but I didn't count the recursions correctly.
After doing some research about the stack and the stack overflow I was getting, I was under the impression that it was simply an issue with recursion. After modifying my program to remove the recursive part of my function, I settled with a while loop. I figured, HA! I solved it now. That was until I ran it. This time I didn't get a stack overflow error, the program just stopped running, and at the same exact spot as before.
The cursor blinks, as if it's thinking, but even letting it sit for several minutes, it does nothing. What other alternatives do I have to get around this? Am I not going to be able to brute force my way to my solution?
That's not it, it's impossible to get zero as a result, one, purely by doing math it's impossible unless the computer calculates something incorrectly, and two bc the rules state a zero can not happen.
Edit: I did put in a case for 0 btw, and it did not solve the issue.
With recursive algorithms, you have to clearly identify the end conditions and define approprate actions for them. If you don't you end up with "unexpected" recursion. I think that's what's happened somehow.
But as I recall, all recursive algorithms can be expressed with loops.
It's definitely not an issue of an unlimited recursive call. 1 HAS to be the bottom value, and it works it's way back up. I have also eliminated the recursive function altogether. Now, I just have a simplified function that finds out if the number is even or odd and manipulates it accordingly. I have it nest in a while loop, and I have no issues until I get to the same exact spot. This is no longer an issue with recursion, but a certain number keeps breaking my formula.
I'm at a lost as to what to do, and I wasn't going to post it bc I want others to have a fair chance at completing the problem as well.
I don't understand, I started my for loop at 2, never had an issue, then I start it at 0, and I had an issue with the number 1, now there is absolutely no issue since I changed the while loop from != 1 to > 1...HOW DID YOU KNOW?!?!
More importantly, if the instructions say 0 can't happen, wtf just happened?
I think that at that very number (113383) the program crashes becouse the numbers become too big! when I changed the return type and the type of the arument to the function iterativeSequence() from intto longlong, it worked PERFECTLY! And also, in just 248 recursive calls(with int it was to 65078 and then it crashed)