Re: Heap in quadcc

[Rik]

On 02/02/2013 09:09 AM, address@hidden wrote:
> Message: 5
> Date: Sat, 2 Feb 2013 11:08:53 -0500
> From: Mike Miller <address@hidden>
> To: Daniel J Sebald <address@hidden>
> Cc: Octave Maintainers <address@hidden>
> Subject: Re: Segfault with Java and "make check"
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> 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.
Yes.  These issues can be really difficult to nail down so I wanted to move
slowly in a stepwise fashion.  As a temporary fix I will reduce the number
of singularities.  The next step is to re-code it to use the heap.  But
like layers of the onion, this has led me to discover a problem with quadcc
when the singularity is located exactly at 0.  The original coder was quite
responsive so I will contact them about that.

>
> 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.
Good definitive test.

--Rik