octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53653] colloc crash


From: Rik
Subject: [Octave-bug-tracker] [bug #53653] colloc crash
Date: Sat, 14 Apr 2018 12:15:12 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #2, bug #53653 (project octave):

Adding jwe to the CC list since it appears that it as this cset that
introduced the problem


changeset:   10603:d909c4c14b63
user:        John W. Eaton <address@hidden>
date:        Tue May 04 13:00:00 2010 -0400
summary:     convert villad functions to C++


For reference, this isn't actually a segfault due to a memory overrun, but
rather the failure of a C assert statement.  Using the 4.3.90 release
candidate,


octave:1> colloc (1)
octave-cli: liboctave/numeric/CollocWt.cc:156: bool jcobi(octave_idx_type,
octave_idx_type, octave_idx_type, double, double, double*, double*, double*,
double*): Assertion `nt > 1' failed.
fatal: caught signal Aborted -- stopping myself...
Abort


At least the message is clear about where the issue is and what the problem
is.  Looking at the code around line 156 it is


static bool
jcobi (octave_idx_type n, octave_idx_type n0, octave_idx_type n1,
       double alpha, double beta, double *dif1, double *dif2,
       double *dif3, double *root)
{
  assert (n0 == 0 || n0 == 1);
  assert (n1 == 0 || n1 == 1);

  octave_idx_type nt = n + n0 + n1;

  assert (nt > 1);


nt is 1 in this case which is the problem.  On the other hand, the original
Fortran for this routine which was converted in cset 10603 is


-C
-      IF ((N + N0 + N1) .LT. 1) THEN
-        IER   = 7
-        LSTOP = .TRUE.
-        CALL VILERR(IER,LSTOP)
-      ELSE
-      END IF
-C


It seems like the actual error condition is 


  if (nt < 1) then


which can be negated for the assert statement to


assert (nt >= 1);


I checked in a small cset to do that:
http://hg.savannah.gnu.org/hgweb/octave/rev/db31e068f4db.

I suppose the next question is whether we really need assert statements here. 
Wouldn't it be better to call liboctave_error_handler and allow the
interpreter to continue rather than crashing out of the program?

Maybe we should grep for other asserts in liboctave.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53653>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]