[nico20]

hi ! i'm currently trying to compile/run code, written for Linux, on X, but i have a strange problem with recursive functions : i get a segmentation fault after about 6000 calls, and gdb give me an allocation error on __swrite (??)
For exemple even this very simple code (without interest, but that should work) doesn't work !

unsigned long sum(unsigned long i)
{
if (i == 1) return 1;
return i+sum(i-1);
}

void main(){
unsigned long s;
s = sum(0xffff);
}

is it only on my computer ?? is it a known problem/limitation ?
thanks
nico.

[sambeau]

I can answer your first question. It seg faults on my G3 too. Why we should run out of stack space so early I have no idea..

[bobDalgleish]

Originally posted by nico20:
<STRONG>hi ! i'm currently trying to compile/run code, written for Linux, on X, but i have a strange problem with recursive functions : i get a segmentation fault after about 6000 calls, and gdb give me an allocation error on __swrite (??)
For exemple even this very simple code (without interest, but that should work) doesn't work !

unsigned long sum(unsigned long i)
{
if (i == 1) return 1;
return i+sum(i-1);
}

void main(){
unsigned long s;
s = sum(0xffff);
}

is it only on my computer ?? is it a known problem/limitation ?
thanks
nico.</STRONG>

RISC processors often consume more stack space than their older cousins. More context, more used registers etc.

The first question is: how many recursions do you think it should take to overflow the stack?

The second question is: why are you doing recursion for large scale production code?

The third question is: have you looked at the load option to set the stack size?

I don't want to know your answers to any of the questions; they are just questions that any competent programmer has in his bag.

[sambeau]

The first question is: how many recursions do you think it should take to overflow the stack?

The second question is: why are you doing recursion for large scale production code?

Well, I can't speak for Nico but I must admit I would have expected more than 6000. You're not going to get very far with a simple recursive quicksort in that environment. Most game playing algorithms would be scuppered, too.

As to using recursion: in this day and age the overhead won't make much difference for most projects. Plus you get very readable maintainable code. Quicksort written recursively is instantly understandable. Non recursively its a nightmare. I'd hate to have to write a parser without it, too.

I, generally, will always choose a juicy recursive algorithm over a fiddly for-loop.

[aleph_null]

<STRONG>6000</STRONG>

I actually found that the exact place it segfaults changes. Put in 30000 and it dies around 23000. Put in 10000 and it dies around 3000.

&lt;shrug&gt;
ya got me...

<STRONG>I, generally, will always choose a juicy recursive algorithm over a fiddly for-loop. </STRONG>

Me, too.

[ 06-12-2001: Message edited by: aleph_null ]

[aleph_null]

Oh. I'm a dork.

It's not that it's actually dying after a different number of frames. It's that my printfs are counting backwards, so of course the number they get to counting down is different for a different starting number.

&lt;smack&gt;

[lindberg]

The stacksize is actually a user limit -- by default, it's 512K. If you want it bigger, you can use "limit stacksize &lt;size&gt;" or "unlimit stacksize" on the command line ("ulimit stacksize" with some shells). In code, you can use the getrlimit()/setrlimit() functions to get/set the variable. The system will still impose a limit, but it looks like it's on the order of 64M.

[nico20]

thank you lindberg for your answer !!

but don't you think the default limitation of 512Kb is a little small, since "Stack extension is performed automatically by the system" ? on Linux (RedHat 7) the default max size is set to 8Mb !

for info, problems came from recursive fonctions for finding strong connected components in graphs. it s really really easier and faster to write it recursive (i agree with sambeau on that point) , and it was even, in most cases, faster than an iterative equivalent (maybe not optimized, i didn't have enough time). but i admit that in some extreme cases it can go as deep as the number of vertices of the graph...