at the expense/risk of (potentially) increased address space fragmentation (and hence (even?) less scalability with large amounts of data), but for the sake of more robust XQuery query translation ((even?) for rather simple queries), I doubled the THREAD_STACK_SIZE on 32-bit systems to 2*512*1024 bytes.
at the expense/risk of (potentially) increased address space fragmentation
(and hence (even?) less scalability with large amounts of data),
but for the sake of more robust XQuery query translation
((even?) for rather simple queries),
I doubled the THREAD_STACK_SIZE on 32-bit systems to 2*512*1024 bytes.

Background:
On two of our 32-bit test platforms (Darwin 8.7.0 on G5 & Fedora Core 4 on Athlon),
various pathfinder tests fail with segfaults caused by stack overflows in BURG
related code, in particular the (highly?) recursive `reduce()' in
pathfinder/compiler/core/fs.brg --- on other 32-bit platforms
(Gentoo 1.12.4 on Athlon, SuSE 9.3 on P4 Xeon, Solaris 10 x86 on Athlon),
these problems do not occur.
The failing pathfinder tests are:
tests/XMark/Tests/: q15 & q16
tests/XMark/mod/XQ/Tests/: q01 - q20
tests/XMark/opt/XQ/Tests/: q01 - q20
tests/XPath/Tests/: q02
tests/XRpc/xmark_queries/Tests/: q01 - q20

At least on Fedora Core 4 on Athlon, these tests work fine with the increased
stack size. Tonight's testing will reveal, whether it also helps on 32-bit Darwin.


In general, we should consider making the BURG-generated and -related code more
robust against stack overflow, by checking the stacksize in recursions and fail
with a proper error message instead of a segfault, in case the stack space is
(about to be) exceeded.
Additionaly, we might consider making the THREAD_STACK_SIZE a configuable
runtime parameter.

zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb,zyzyis/monetdb