Fri 09 Jul 2010 12:23:48 PM UTC, comment #9:
I've just discovered that the bug has already been reported (#0059) and LAPACK SVN now contains corrected formulas. Apparently both the docs and the automatic query are broken up to 3.2.1. So it seems we won't be able to switch to the auto queries any time soon :( At least in this case.
I updated (add87b12e63c) Octave to use the corrected formulas rather than my previous ad hoc adjustment. The bug is gone, which is a good omen.
Closing the bug. John, if you still want the testcase, mail me.
|
Wed 23 Jun 2010 04:16:25 PM UTC, comment #8:
Could you please post the Fortran code for the test case?
|
Wed 16 Jun 2010 12:39:40 PM UTC, comment #7:
I've isolated the problem to a Fortran testcase. I'll submit a bug report to LAPACK when there's time. I have no proof for this, but adding 1 to NLVL in that calculation seems to be a sufficient workaround. I did it and marked as FIXME in the source code:
http://hg.savannah.gnu.org/hgweb/octave/rev/2786b7ae3f80
|
Wed 16 Jun 2010 11:03:33 AM UTC, comment #6:
I can't reproduce this, but I'm not surprised, gdb occassionally gives me garbage, too. For instance, I now see
(gdb) p*retval.rep
Cannot access memory at address 0x0
I'd say that gdb is just confused.
I'll try to reproduce the error with stand-alone program, perhaps I'll be more lucky.
|
Fri 11 Jun 2010 05:44:01 PM UTC, comment #5:
While trying to debug what is happening in ComplexMatrix::lssolve in the current development sources, I am seeing some strange things. For example, if I set a breakpoint at the first line in ComplexMatrix::lssolve where retval is declared and step just past this line, gdb tells me
(gdb) p *retval.rep
$35 = {
data = 0xa17400,
len = 119,
count = 0
}
I don't see how this can happen, and it looks like trouble for the count to be zero in an ArrayRep object.
Jaroslav, can you explain what is going on here?
|
Fri 11 Jun 2010 04:37:44 PM UTC, comment #4:
Oops, my previous program had a stupid error in it. I'm attaching a corrected version. However, this version appears to work correctly on my system, so now I'm not sure what the problem is. If it is a bug in Octave, then I would guess we are calling zgelsd incorrectly, but I'm not seeing the error yet...
(file #20736)
|
Thu 10 Jun 2010 05:01:07 PM UTC, comment #3:
I'm attaching a fortran program that also crashes on my system when compiled with
gfortran zgelsd-bug.f -llapack -lblas
(file #20729)
|
Fri 04 Jun 2010 08:35:57 AM UTC, comment #2:
The problem seems to be with RWORK size calculation for ZGELSD. I didn't, however, discover any difference between Octave's formula and the ZGELSD docs, suggesting that this may be a bug in LAPACK. I'll try to narrow it down to a stand-alone test case.
|
Fri 04 Jun 2010 05:02:59 AM UTC, comment #1:
Confirmed on a development tip (10680:e00de2d5263c) on an x86_64 GNU/Linux system.
|
Thu 03 Jun 2010 04:51:08 PM UTC, original submission:
Here is how octave generates a coredump using Debian Etch, v. 3.2.4 (same happens for Ubuntu Jaunty, v. 3.0.1).
%> /usr/bin/octave -fq
octave:1> load foo.ob
octave:2> whos
Variables in the current scope:
Attr Name Size Bytes Class
==== ==== ==== ===== =====
ans 1x11 92 cell
x 119x119 226576 double
y 119x119 226576 double
Total is 28333 elements using 453244 bytes
octave:3> x \ y ;
warning: matrix singular to machine precision, rcond = 3.61519e-19
warning: attempting to find minimum norm solution
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault
|