Re: Segfault with Java and "make check"

[Mike Miller]

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.

-- 
mike