On Sat, Feb 2, 2013 at 1:42 AM, Daniel J Sebald wrote:
I took a look at quadcc.cc and it is not recursion that is the problem.
It
simply implements some huge local variables on the stack that should
probably be allocated from the heap instead. There is a #define in the
code that controls how many singularities can be passed to the function.
/* Define the size of the interval heap. */
#define cquad_heapsize 200
The current value is 200 which leads to ~322 kB worth of local variables
on
the stack. I think that specifying 50 singularities along an integral
path
would probably be plenty. As a quick fix, does changing line 40 of
corefcn/quadcc.cc to 50 solve the problem?
Not very efficient coding there. Is the stack size always fixed for Octave?
Or is that a system level thing? If it is system level, some other
operating system could have similar problems with the number 50 as opposed
to 200. That's not the type of thing that should be on a stack, but the
heap. (We had a discussion about this sort of thing at OctConf2012.)
Yes, this was just a quick check to verify the problem, Rik did
suggest moving it to the heap as a real solution.
The stack size is a configurable per-process resource on Unix-like
systems, see ulimit, setrlimit, RLIMIT_STACK.
If I reduce my stack size to 64 kB (ulimit -s 64 in bash) and run
"make check" it segfaults again on dblquad even with this patch
applied.