Re: Segfault with Java and "make check"

[Mike Miller]

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.

-- 
mike