Home > Archive > VC Language > June 2005 > Stack Overflow
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi All,
What cause a Stack Overflow?
Is it that the program used more memory than that was alloted for it?
I converted my application to Unicode and it statredgiving this problem.
It's not getting stuck in an infinite loop, and if I step into it, it's not
getting stuck at any particular line which is alotting any memory, it crashes
at the beginning of a function. Maybe since I converted all those chars to
TCHARs now it's using up double the memory, and running out of memory????
Plese enlighten me
Thanks a lot in advance
Srishti
| |
| Igor Tandetnik 2005-06-05, 8:58 pm |
| "Sonu" <sonu@online.nospam> wrote in message
news:1A887820-41D9-4CF6-A1F3-914205F530F6@microsoft.com
> What cause a Stack Overflow?
Two common causes are 1) runaway recursion, and 2) declaring large
arrays as local variables.
> Is it that the program used more memory than that was alloted for it?
Kind of. Specifically, more _stack_ memory. Stack is used for local
variables and function parameters, and its size is limited.
> I converted my application to Unicode and it statredgiving this
> problem. It's not getting stuck in an infinite loop, and if I step
> into it, it's not getting stuck at any particular line which is
> alotting any memory, it crashes at the beginning of a function.
This sounds like cause #2 - large arrays declared as local variables.
Avoid code like this:
void f()
{
char localVar[LARGE_VALUE];
}
Allocate large arrays on the heap instead.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
|
| Thanks a "heap"
That should help, I'll go change all those "memory suckers" right away!!! :)
Thanks
Srishti
"Igor Tandetnik" wrote:
> "Sonu" <sonu@online.nospam> wrote in message
> news:1A887820-41D9-4CF6-A1F3-914205F530F6@microsoft.com
>
> Two common causes are 1) runaway recursion, and 2) declaring large
> arrays as local variables.
>
>
> Kind of. Specifically, more _stack_ memory. Stack is used for local
> variables and function parameters, and its size is limited.
>
>
> This sounds like cause #2 - large arrays declared as local variables.
> Avoid code like this:
>
> void f()
> {
> char localVar[LARGE_VALUE];
> }
>
> Allocate large arrays on the heap instead.
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>
>
| |
| Simon Trew 2005-06-07, 3:58 am |
| Don't you think it rather a peculiar thing that the stack is often
considered infinite (when it patently isn't) whereas the heap might fail at
any time? I'm thinking of patterns such as RAII and, er, function calling
(parameter and return value passing), that rely on the stack never failing.
I'm sure a language lawyer can argue that the C++ spec makes no requirement
for a stack, but it does make requirements for some kind of stack-like
behavior. Don't you think that a stack overflow (or rather an inability to
call or return from a function, or allocate its local data slots), should be
a proper C++ exception? Of course, there would be the usual grave problems
with how that exception percolated and what was cleaned up.
S.
| |
| Tim Roberts 2005-06-07, 3:58 am |
| "Simon Trew" <ten.enagro@werts> wrote:
>
>I'm sure a language lawyer can argue that the C++ spec makes no requirement
>for a stack, but it does make requirements for some kind of stack-like
>behavior. Don't you think that a stack overflow (or rather an inability to
>call or return from a function, or allocate its local data slots), should be
>a proper C++ exception? Of course, there would be the usual grave problems
>with how that exception percolated and what was cleaned up.
I would guess that there are many reasonable architectures in which a stack
overflow cannot be reliably detected, or at least at reasonable expense.
That in itself probably deterred the standards committee from saying much
about it.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc
| |
| Simon Trew 2005-06-08, 8:59 pm |
| "Tim Roberts" <timr@probo.com> wrote in message
news:77aaa1lvi48bc1rms34ja3g53cs1hpt7dc@
4ax.com...
> I would guess that there are many reasonable architectures in which a
> stack
> overflow cannot be reliably detected, or at least at reasonable expense.
> That in itself probably deterred the standards committee from saying much
> about it.
Yes, but I still find it a little odd that no mention is made about what
happens if automatic storage cannot be allocated (in e.g. 3.7.2
[basic.stc.auto]). Probably I am looking in the wrong places.
S.
|
|
|
|
|