Hello,
Anyway even if you have to use another API for large stack, it must not result in a segfault if you don't use it and have problems with the other one but in a nice handled error message telling you to use the good API or there is a flaw in Pike.
Besides you usually never know for sure you won't have large amount of svalues on the stack if there is a link with user input so I think that every program should use the macros you speak about for any user input.
BTW are you coming to the Pike camp?
/ David
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
C functions that might consume lots of stack should use check_stack to cover their needs, and maybe also check_c_stack if they recurse heavily. The main apply function checks that there are 256 svalues available on the pike stack before the call, so that "normal" functions don't need to bother with it.
C functions should never aggregate arbitrarily large amounts of svalues on the stack (e.g. to build an array). There are some helper macros to safely aggregate an array using the stack - see (BEGIN|DO|END)_AGGREGATE_ARRAY near the end of array.h.
On the pike level it's unwise to splice arbitrarily large arrays, e.g. with constructs like `+(@large_array).
/ Martin Stjernholm, Roxen IS
Previous text:
2004-10-13 09:25: Subject: Mysterious segfault... solved by increasing -s...
Hi,
Playing with sqlite module (by Bill), got some mysterious segfault after ca. 140K rows were returned... It was completely mysterious, pointing to places like:
push_text("val"); // I replaced original to test it...
where all variable values were normal (according to gdb), but valgrind went crazy... Well... The story finished when I started pike with -s1000000 - everything is OK - despite the fact that processing of 1000000 rows takes ca. 500M or RAM :)
So... The question... Isn't something that is controlled by -s (pike stack, I guess - values are accumulated on stack before aggregation) supposed to check stack size against oversizing? functions like push_* or whatever? To be honest, it took me few hours of hunting without any clue about reasons - and totally useless coredumps, valgrind reports, etc...
Ah... It was tried with pike 7.6.24... Not sure if this is relevant, but I remember that early (some time ago) I got a message like "Stack overflow" from Pike, when it was too small (even without --rtl-debug etc.).
NB: Bill, there are some troubles with sqlite3 support - I fixed them and will send a patch to you shortly... Unless you fixed those already :)
Regards, /Al
/ Brevbäraren