Re: Segfault with Java and "make check"

[Rik]

On 01/31/2013 10:00 AM, address@hidden wrote:
> Message: 3
> Date: Thu, 31 Jan 2013 08:40:41 -0500
> From: Mike Miller <address@hidden>
> To: Julien Bect <address@hidden>
> Cc: address@hidden
> Subject: Re: Segfault when running "make check"
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Jan 31, 2013 at 5:54 AM, Julien Bect wrote:
>> > Julien Bect wrote
>>> >>
>>> >> Mike Miller-2 wrote
>>>> >>> $ ./run-octave -qf --eval 'o = javaObject ("java.lang.Object"); test
>>>> >>> dblquad'
>>>> >>> Segmentation fault
>>> >> Here is the result of valgrind on this command :
>>> >> valgrind.out.jbect.20130131
>>> >> <http://octave.1599824.n4.nabble.com/file/n4649305/valgrind.out.jbect.20130131>
>> >
>> > I have reverted from openjdk-7 (7u9-2.3.4-0ubuntu1.12.10.1) to openjdk-6
>> > (6b24-1.11.5-0ubuntu1~12.10.1) and rebuilt Octave.
>> >
>> > "make check" run fine now.
> I get similar valgrind results, with the last error in the report:
>
> ==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.

If this works we may want to investigate limiting how much memory the JVM
takes for itself, particularly in 32-bit environments.

--Rik