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.
|
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.
|
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.
|
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.
MATLAB R2012a:
does not throw an error, only displays a warning (but it's somewhat inconsistent: sometimes it doesn't even display a warning).
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
|
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?
|
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
|
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:
(file #25672)
|
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.
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
|
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:
...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".
|
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:
It then says "DLASCL4" and is gone ... The exit code is 0.
2) Endless loop (stoppable with Ctrl-C).
|