[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Avoiding recursive stack overflow in C on Unix/Linux?

boltar2003

5/5/2011 9:38:00 AM

Hello

If a program recurses too deeply there's always a chance that it could
run out of stack space and die with a SIGSEGV. Is there any API that can
tell you how much stack space is left or some other method to prevent this
in C/C++? I realise I could catch the signal but thats a pretty damn ugly
way to do it.

B2003
239 Answers

China Blue Veins

5/5/2011 9:52:00 AM

0

In article <iptr5l$tkb$1@speranza.aioe.org>, boltar2003@boltar.world wrote:

> Hello
>
> If a program recurses too deeply there's always a chance that it could
> run out of stack space and die with a SIGSEGV. Is there any API that can
> tell you how much stack space is left or some other method to prevent this
> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
> way to do it.
>
> B2003

On some systems there is setrlimit which can be used to set the stack size. On
unix you can start with 'man -k limit' and examine individual man pages.

--
Damn the living - It's a lovely life. I'm whoever you want me to be.
Silver silverware - Where is the love? At least I can stay in character.
Oval swimming pool - Where is the love? Annoying Usenet one post at a time.
Damn the living - It's a lovely life. Why does Harmony have blue veins?

boltar2003

5/5/2011 9:58:00 AM

0

On Thu, 05 May 2011 02:51:35 -0700
China Blue Veins <chine.bleu@yahoo.com> wrote:
>In article <iptr5l$tkb$1@speranza.aioe.org>, boltar2003@boltar.world wrote:
>
>> Hello
>>
>> If a program recurses too deeply there's always a chance that it could
>> run out of stack space and die with a SIGSEGV. Is there any API that can
>> tell you how much stack space is left or some other method to prevent this
>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
>> way to do it.
>>
>> B2003
>
>On some systems there is setrlimit which can be used to set the stack size. On
>unix you can start with 'man -k limit' and examine individual man pages.

Actually I suppose i could use getrlimit to get the stack size but is there
a clean way of actually finding the current position of top of the stack? I
could take the addresses of local variables but that seems a bit prone to
error.

B2003

Xavier Roche

5/5/2011 9:59:00 AM

0

On 05/05/2011 11:37 AM, boltar2003@boltar.world wrote:
> If a program recurses too deeply there's always a chance that it could
> run out of stack space and die with a SIGSEGV. Is there any API that can
> tell you how much stack space is left or some other method to prevent this
> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
> way to do it.

There is no portable way to find the stack bottom/size ; I am not even
sure what getrlimit(RLIMIT_STACK) returns exactly (current thread stack
size ? main thread stack size ? default stack size ?)

(And there is no portable way to find the stack top/bottom -- you'll
have to play with an address on the current stack around main, and play
with arithmetics with the page size)

China Blue Veins

5/5/2011 11:48:00 AM

0

In article <iptsbq$t3$1@speranza.aioe.org>, boltar2003@boltar.world wrote:

> On Thu, 05 May 2011 02:51:35 -0700
> China Blue Veins <chine.bleu@yahoo.com> wrote:
> >In article <iptr5l$tkb$1@speranza.aioe.org>, boltar2003@boltar.world wrote:
> >
> >> Hello
> >>
> >> If a program recurses too deeply there's always a chance that it could
> >> run out of stack space and die with a SIGSEGV. Is there any API that can
> >> tell you how much stack space is left or some other method to prevent this
> >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
> >> way to do it.
> >>
> >> B2003
> >
> >On some systems there is setrlimit which can be used to set the stack size.
> >On
> >unix you can start with 'man -k limit' and examine individual man pages.
>
> Actually I suppose i could use getrlimit to get the stack size but is there
> a clean way of actually finding the current position of top of the stack? I
> could take the addresses of local variables but that seems a bit prone to
> error.

If you can decipher the code, the Boehm garbage collector/allocator can get the
entire stack for a variety of systems.

--
Damn the living - It's a lovely life. I'm whoever you want me to be.
Silver silverware - Where is the love? At least I can stay in character.
Oval swimming pool - Where is the love? Annoying Usenet one post at a time.
Damn the living - It's a lovely life. Why does Harmony have blue veins?

Kleuskes & Moos

5/5/2011 7:24:00 PM

0

On May 5, 11:37 am, boltar2...@boltar.world wrote:
> Hello
>
> If a program recurses too deeply there's always a chance that it could
> run out of stack space and die with a SIGSEGV. Is there any API that can
> tell you how much stack space is left or some other method to prevent this
> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
> way to do it.
>
> B2003

The only proper way to avoid stack-overflows is to prevent it from
happening in the first place. If at all possible (and frequently it
is) avoid recursion, if it's unavoidable, as it sometimes is, make
sure your design prevents those situations from arising in the first
place.

Trying to solve a design problem by imposing artificial limitations
seems a bad idea.

Lowell Gilbert

5/5/2011 7:40:00 PM

0

"Kleuskes & Moos" <kleuske@xs4all.nl> writes:

> On May 5, 11:37 am, boltar2...@boltar.world wrote:
>> Hello
>>
>> If a program recurses too deeply there's always a chance that it could
>> run out of stack space and die with a SIGSEGV. Is there any API that can
>> tell you how much stack space is left or some other method to prevent this
>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
>> way to do it.
>>
>> B2003
>
> The only proper way to avoid stack-overflows is to prevent it from
> happening in the first place. If at all possible (and frequently it
> is) avoid recursion, if it's unavoidable, as it sometimes is, make
> sure your design prevents those situations from arising in the first
> place.
>
> Trying to solve a design problem by imposing artificial limitations
> seems a bad idea.

Without in any way disagreeing, I can't imagine being able to come up
with a contextual definition for "artificial" in that sentence.

--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.or...

Ben Bacarisse

5/5/2011 8:17:00 PM

0

"Kleuskes & Moos" <kleuske@xs4all.nl> writes:

> On May 5, 11:37 am, boltar2...@boltar.world wrote:
>> If a program recurses too deeply there's always a chance that it could
>> run out of stack space and die with a SIGSEGV. Is there any API that can
>> tell you how much stack space is left or some other method to prevent this
>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
>> way to do it.
>
> The only proper way to avoid stack-overflows is to prevent it from
> happening in the first place. If at all possible (and frequently it
> is) avoid recursion, if it's unavoidable, as it sometimes is, make
> sure your design prevents those situations from arising in the first
> place.

I find this answer interesting, mainly because I think is suggests a
very different view about programming. I would not try to avoid
recursion "if at all possible". In general I consider that it is up to
the system to provide the resources needed by a program and this
includes stack for a reasonable amount of recursion. These resources
can run out of course, and the stack is special in that few languages
provide any way to handle its exhaustion elegantly, but that does not
seem enough reason to design out all recursion.

There are special cases: some environments are severely resource limited
but there's no indication that the OP is using such a system and,
anyway, I don't think you can make general rules from specific situations.

> Trying to solve a design problem by imposing artificial limitations
> seems a bad idea.

Isn't this what you are doing? Isn't the ban on recursion not an
artificial limitation?

--
Ben.

Datesfat Chicks

5/5/2011 10:46:00 PM

0

On Thu, 05 May 2011 21:17:09 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
>
>> On May 5, 11:37 am, boltar2...@boltar.world wrote:
>>> If a program recurses too deeply there's always a chance that it could
>>> run out of stack space and die with a SIGSEGV. Is there any API that can
>>> tell you how much stack space is left or some other method to prevent this
>>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
>>> way to do it.
>>
>> The only proper way to avoid stack-overflows is to prevent it from
>> happening in the first place. If at all possible (and frequently it
>> is) avoid recursion, if it's unavoidable, as it sometimes is, make
>> sure your design prevents those situations from arising in the first
>> place.
>
>I find this answer interesting, mainly because I think is suggests a
>very different view about programming. I would not try to avoid
>recursion "if at all possible". In general I consider that it is up to
>the system to provide the resources needed by a program and this
>includes stack for a reasonable amount of recursion. These resources
>can run out of course, and the stack is special in that few languages
>provide any way to handle its exhaustion elegantly, but that does not
>seem enough reason to design out all recursion.
>
>There are special cases: some environments are severely resource limited
>but there's no indication that the OP is using such a system and,
>anyway, I don't think you can make general rules from specific situations.
>
>> Trying to solve a design problem by imposing artificial limitations
>> seems a bad idea.
>
>Isn't this what you are doing? Isn't the ban on recursion not an
>artificial limitation?

The restrictions on stack depth are no different than the restrictions
on memory size or disk space that are present on any computer system.

These limits have been relaxed over time, and certainly programs will
run today on a typical computer that would not have run 10 years ago
on a typical computer.

"Don't use recursion" seems to be logically the same as "don't declare
very large arrays" or "don't create really big files". It is
dependent on the technology of the day, rather than being an absolute
standard.

These days I have a few files on my server that are on the order of
20G. That would have been unthinkable 10 years ago.

DFC

James Kuyper

5/6/2011 12:07:00 AM

0

On 05/05/2011 03:24 PM, Kleuskes & Moos wrote:
> On May 5, 11:37�am, boltar2...@boltar.world wrote:
>> Hello
>>
>> If a program recurses too deeply there's always a chance that it could
>> run out of stack space and die with a SIGSEGV. Is there any API that can
>> tell you how much stack space is left or some other method to prevent this
>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
>> way to do it.
>>
>> B2003
>
> The only proper way to avoid stack-overflows is to prevent it from
> happening in the first place.

And how do you do that? If the stack size is sufficiently limited, even

int main(int argc, char*argv[]) { return 0; }

could overflow the stack.
You can take measures to reduce the likelihood of overflow, but there's
no easy way to know whether you've done enough. And doing enough on one
system might be a complete waste of time on others. The systems I use
most frequently allow me to put a gigabyte or more of data on the stack;
other systems are far more limited.

....
> Trying to solve a design problem by imposing artificial limitations
> seems a bad idea.

So what's the design solution you propose to "prevent overflow"?

--
James Kuyper

Ben Bacarisse

5/6/2011 1:54:00 AM

0

James Kuyper <jameskuyper@verizon.net> writes:

> On 05/05/2011 03:24 PM, Kleuskes & Moos wrote:
>> On May 5, 11:37�am, boltar2...@boltar.world wrote:
>>> Hello
>>>
>>> If a program recurses too deeply there's always a chance that it could
>>> run out of stack space and die with a SIGSEGV. Is there any API that can
>>> tell you how much stack space is left or some other method to prevent this
>>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly
>>> way to do it.
>>>
>>> B2003
>>
>> The only proper way to avoid stack-overflows is to prevent it from
>> happening in the first place.
>
> And how do you do that? If the stack size is sufficiently limited, even
>
> int main(int argc, char*argv[]) { return 0; }
>
> could overflow the stack.

Hmm... only in the most contrived implementation. The standard mandates
that an implementation must be able to translate and run at least one
program that is very much more complex than this. The system would have
to penalise simple, small programs deliberately!

It's a detail. I agree with your point that almost any call can be the
one that causes a stack overflow. Recursion need not be to blame.

<snip>
--
Ben.