Re: Segfault with Java and "make check"

[Daniel J Sebald]

On 02/01/2013 05:58 PM, Rik wrote:
> On 02/01/2013 11:50 AM, Mike Miller wrote:
> > On Fri, Feb 1, 2013 at 11:40 AM, Rik wrote:
> > > > [...]
> > > > ==27366== Can't extend stack to 0xfe857600 during signal delivery for thread 1:
> > > > ==27366==   too small or bad protection modes
> > > >
> > > > seems to confirm what I ran into working on bug #37891, that Java uses
> > > > up a lot of the process stack space allocation just being resident and
> > > > some algorithms that worked fine before are failing when they can't
> > > > allocate another stack frame.
> > > 2/1/13
> > >
> > > Mike,
> > >
> > > This seems like  a reasonable supposition.  The quadcc algorithm uses
> > > adaptive rules which involve recursively subdividing the integration
> > > region.  When the function is smooth the process doesn't go very far.
> > > Around singularities or discontinuities the algorithm has to shrink the
> > > integration step size to small values to ensure it maintains the overall
> > > accuracy desired.  This would mean lots of recursion.
> > >
> > > Checking dblquad.m, I see that the first test is:
> > >
> > > %% Nasty integrand to show quadcc off
> > > %!assert (dblquad (@(x,y) 1 ./ (x+y), 0, 1, 0, 1), 2*log (2), 1e-6)
> > >
> > > This certainly has a singularity at (0,0) which is going to cause lots of
> > > stack frames.
> > >
> > > In the interests of thoroughness, could you re-compile on 32-bit with Java
> > > enabled and verify that "make check" still produces a segfault?  Then I
> > > would like to try modifying dblquad to use a different default integration
> > > algorithm and see if it that stops the problem.
> > >
> > > The line to modify is the function header in scripts/general/dblquad.m.
> > >
> > > Change
> > > function q = dblquad (f, xa, xb, ya, yb, tol = 1e-6, quadf = @quadcc, varargin)
> > > to
> > > function q = dblquad (f, xa, xb, ya, yb, tol = 1e-6, quadf = @quadgk, varargin)
> > >
> > > Then verify whether "make check" still segfaults in dblquad.  I'm hoping it
> > > won't which will prove this supposition.  It's very likely though that the
> > > overall "make check" will segfault when it reaches triplequad.m.  You could
> > > change that function header as well if you wanted.
> > Good suggestions, I tried that and a bit more to be thorough.
> >
> > First off, a fresh 32-bit build with --disable-java did not segfault
> > during "make check" under any circumstances.
> >
> > Back to the 32-bit Java-enabled build, I changed the default to quadgk
> > as you suggested and "make check" does indeed finish. I didn't look
> > too closely, but triplequad succeeds without any changes as long as
> > dblquad's default is not quadcc.
> >
> > Next I reverted that change and just commented out all tests that are
> > conditional on HAVE_JAVA and "make check" again finishes successfully.
> 2/1/13
>
> Mike,
>
> Your tests seems pretty clear which is good news.
>
> 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.)

Dan