Re: Segfault with Java and "make check"

[Daniel J Sebald]

On 02/02/2013 11:20 AM, PhilipNienhuis wrote:
> Daniel Sebald wrote
> > On 02/02/2013 10:08 AM, Mike Miller wrote:
> > > 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.
> >
> > OK, nice check.  Seems to verify just what is happening.
>
> The intruiging thing is that it does not segfault in the GUI.
> Doing:
>
> cd<OctaveSRC>/test
> fntests
>
> makes the CLI segfault but not the GUI.
> What is different in the GUI that it behaves more robust than the CLI (...in
> this respect)?

That is interesting, but it is difficult to say what exactly is 
happening.  A stack overrun sort of causes random behavior.  It could be 
that running the GUI either puts the stack in a different location in 
memory (less likely) or that the stack pointer starts out at a different 
location when running the integration routine (more likely).  We aren't 
certain that the integration routine is using the stack variables in a 
contiguous fashion.  In one case it might obliterate something 
immediately problematic as far as instruction code, in another case it 
might be lucky and not cause any damage.  Or worse, there can be some 
type of damage that isn't immediately obvious but shows in other 
peculiar ways.  Stack problems can be really inscrutable.

Dan