bugGNU Octave - Bugs: bug #36211, bug: crashes and endless loops

 
 

bug #36211: bug: crashes and endless loops

Submitter:  None
Submitted:  Mon 16 Apr 2012 04:06:22 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Duplicate Assigned to:  None
Originator Name:  Stefan Reiser Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.6.1
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 11 Jan 2014 08:31:41 PM UTC, comment #9: 

I think the remaining issue here is that Octave is not handling blas/lapack errors on Windows. This is the same as bug #39000. When that bug is fixed, Octave will report that it caught the error as it does on Linux and not exit.

Closing as a duplicate of bug #39000. Please comment or reopen this report if I missed some detail.

Mike Miller <mtmiller>
Group Member
Tue 19 Mar 2013 01:34:13 PM UTC, comment #8: 

Ping - any opinions on how we should resolve this one?

See https://bugs.launchpad.net/bugs/1156575

I believe this Ubuntu bug report is the same underlying bug, that DLASCL aborts on bad arguments. This one has two interesting differences though:

1) XERBLA in LAPACK is being called, not XERBLA in libcruft, at least according to my gdb, any ideas on what is going wrong there?

2) The JVM has been loaded, so when XERBLA calls STOP, Octave's atexit handlers fire, and something in calling the java_exit routine causes Octave to segfault.

If I prevent the Java package from loading, Octave simply exits instead of showing the "exception encountered in Fortran" message, confirming that the wrong copy of XERBLA is called. Still a bad outcome.

Mike Miller <mtmiller>
Group Member
Thu 19 Apr 2012 08:59:22 PM UTC, comment #7: 

Given that the dependency libs (i.e., DLASCL & dgelsd_) can't continue, I suppose the most sensible response would be to throw an error.
I don't trust ML's behavior here; its response may simply be motivated by the desire to allow e.g., batch scripts to continue. I'd prefer that batch processing users take more explicit precautions to catch these error situations themselves, rather then let processing continue, possibly foul up, only to perhaps sort out the problems later on (if warnings are noticed at all in that stage).


(I'm out of here ... after all, I just wanted to report that crash on my windows box, but soon found myself reading fortran sources ;) )

Yes that happens, sorry for that. I think it even resembles the way I got involved here 12 yrs ago :-)

Thanks for reporting anyway.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 19 Apr 2012 12:43:23 PM UTC, comment #6: 

I'm not sure. Throwing an error seems appropriate to me.
I took a look at what others do:

Scilab 5.3.3:
Scilab refuses to calculate with NaN and Inf.


-->A=[1234,%inf];b=[5];A\b;
                        !--error 229
Operands of / and \ operations must not contain NaN or Inf.


MATLAB R2012a:
does not throw an error, only displays a warning (but it's somewhat inconsistent: sometimes it doesn't even display a warning).


>> A=[1234,inf];b=[5];A\b
Warning: Rank deficient, rank = 0, tol =  1.#INF00e+00.

ans =

     0
     0


>> A=[1234,nan];b=[5];A\b
Warning: Rank deficient, rank = 0, tol = NaN.

ans =

     0
     0

>> A=[nan,1234];b=[5];A\b

ans =

         0
    0.0041


Ok ... so, it's for you octave maintainers to decide... (I'm out of here ... after all, I just wanted to report that crash on my windows box, but soon found myself reading fortran sources ;) )
regards
Stefan Reiser

Anonymous
Wed 18 Apr 2012 03:15:01 PM UTC, comment #5: 

Once an Inf (or NaN?) is detected in either operand of \ or /, what should happen?  Should we just throw an error like we do for eig?

John W. Eaton <jwe>
Group administrator
Wed 18 Apr 2012 02:13:04 PM UTC, comment #4: 

I've been looking for a statement that clarifies whether DGELSD claims to check the input (for infinity/NaN values) itself or expects the caller to take care of this.

I could not find anything in the Lapack User Guide or in the source of http://www.netlib.org/lapack/double/dgelsd.f, but here -- http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/win/mkl/refman/lse/lse_intro.html -- it says:

"Warning LAPACK routines require that input matrices do not contain INF or NaN values. When input data is inappropriate for LAPACK, problems may arise, including possible hangs."

So, maybe octave could do a call to "any_element_is_inf_or_nan()" like it already does, for example, for svg () and eig ()?

Regards
Stefan Reiser

Anonymous
Tue 17 Apr 2012 04:25:11 PM UTC, comment #3: 

I'm attaching a very simple Fortran program that calls dgelsd in a way similar to what Octave does from C++ using the values from your test.  It shows the same problems, either an infinite loop or an error in calling dlascl.  The call to dgelsd seems correct to me in this case, and works for other (non-Inf) values of A\b.  So unless someone can show that we are doing the wrong thing in Matrix::lssolve (dMatrix.cc around line 2240), I think the error is in lapack, not Octave, and so should be reported to the lapack maintainers.

On my Debian system, I have the following packages installed:


  libatlas3gf-base                          3.8.3-27
  liblapack3gf                              3.3.1-1



(file #25672)

John W. Eaton <jwe>
Group administrator
Tue 17 Apr 2012 09:52:58 AM UTC, comment #2: 

Hello, thanks for investigating this issue,

I'm using the "i686-pc-mingw32" version of 3.6.1.

yes, I know my statements are somewhat nonsensical :) - I just wanted to create a tiny example. As far as I can see, the loop (or crash) occurs on (every?) equation systems where the matrix contains any Inf value.
I was doing curve fitting with a Gauss-Newton like algorithm (see below) that did not converge, so that after a few iterations there where Inf values in the equation system.


F = f(X,a);   % F: function values
              % a: vector of parameters
              % X,Y: Nx1-matrices with measurement data (N is about 20000)
r = F-Y;      % residuals
J = jac(X,a); % jac: function that forms jacobi-matrix

% (here I should check if there are Inf values in J ...)

s = J \ r;    % crash...
a -= s;
% (...iterate until algorithm converges...)


It seems that if the Inf value is in the first column, then it crashes (or on linux: shows the expected error message). If the Inf is in a column >1 then it is doing it's endless loop.

Regards
Stefan Reiser

Anonymous
Mon 16 Apr 2012 07:14:24 PM UTC, comment #1: 

Having no opinion yet about the statements you use (i.e., calculating with Inf values), on my Mandriva Linux box, running Octave 3.6.1, I see:


octave-3.6.1:1> A=[inf,1234];b=[5];A\b
 ** On entry to DLASCL parameter number  4 had an illegal value
error: exception encountered in Fortran subroutine dgelsd_
octave-3.6.1:1>


...so Octave catches some issues there.
On Windows Octave's error catching may be set up incorrectly. What Windows version do you use, MSVC or MinGW?

I can also confirm the endless loop.

Changed operating system to "any".

Philip Nienhuis <philipnienhuis>
Group Member
Mon 16 Apr 2012 04:06:22 PM UTC, original submission:  

I've experienced some strange crashes during certain calculations. Octave exits without error message and with exit code 0. The crash occurs during equation solving, here are some simple examples to reproduce the situation:

1) unsolvable equation system:

   A=[inf,1234];b=[5];A\b


It then says "DLASCL4" and is gone ... The exit code is 0.


2) Endless loop (stoppable with Ctrl-C).

   A=[1234,inf];b=[5];A\b


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #25672:  dgelsd-bug.f added by jwe (716B - text/x-fortran)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by philipnienhuis (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-11 mtmiller StatusConfirmed Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #39000
    2012-04-17 jwe Attached File- Added dgelsd-bug.f, #25672
    2012-04-16 philipnienhuis StatusNone Confirmed
        Operating SystemMicrosoft Windows Any

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code