Re: Octave 3.3.54 snapshot available for ftp

[Fredrik Lingvall]

On 11/23/10 17:29, Fredrik Lingvall wrote:
> On 11/23/10 09:46, John W. Eaton wrote:
>> I don't see this problem.  Building with --enable-64 works for me on a
>> Debian AMD64 system.
>>
>> Maybe it is related to this reported bug:
>>
>>   https://savannah.gnu.org/bugs/?31734
>>
>> ?  I have not investigated the problem.  I don't really understand the
>> sparse matrix code in Octave very well.
>>
>> If you run
>>
>>   ../../run-octave -f -q -H -p . --eval "sparseimages ('spchol', 'eps');"
>>
>> separate from make, does it crash?  What if you try
>>
>>   ../../run-octave -g -f -q -H -p . --eval "sparseimages ('spchol', 'eps');"
>>
>> That should run the same command but with Octave executing under gdb.
>> Then you could get a backtrace that might give some clues about the
>> crash.
>>
>> jwe
> Yes this pinned it down a bit. The LAPACK routine DPOTRF (Cholesky
> factorization of a real symmetric positive definite matrix) is called in
> the wrong way (or is compiled in the wrong way):
>
> <snip>
>
>  --doc-cache-file=/root/software/octave/hg/octave/doc/interpreter/doc-cache
> --info-file=/root/software/octave/hg/octave/doc/interpreter/octave.info
> -f -q -H -p . --eval sparseimages\ \(\'spchol\',\ \'eps\'\)\;
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7fffe9b88710 (LWP 1643)]
> [New Thread 0x7fffe71a4710 (LWP 1644)]
> [New Thread 0x7fffe69a3710 (LWP 1645)]
>  ** On entry to DPOTRF parameter number  4 had an illegal value
> [Thread 0x7fffe9b88710 (LWP 1643) exited]
> [Thread 0x7fffe71a4710 (LWP 1644) exited]
> [Thread 0x7fffe69a3710 (LWP 1645) exited]
>
> Program exited normally.
> (gdb)
>
> I have this function in Goto blas:
>
> fl-mac lib # nm libgoto2_nehalemp-r1.13.so | grep dpotrf
> 0000000000069d70 T dpotrf_
>
> which is configured with:
>
> TARGET = NEHALEM
> BINARY=64
> NUM_THREADS = 2
> INTERFACE64 = 1
>
> /Fredrik
>
I tested chol before using (almost) the same code as in: 
doc/interpreter/sparseimages.m That is, I used n=100 which worked fine.
However, if I use exactly the same code (n=200) then dpotrf fails!

octave:1> n=200
n =  200
octave:2> a = 10*speye(n) + sparse(1:n,ceil([1:n]/2),1,n,n) + ...
>       sparse(ceil([1:n]/2),1:n,1,n,n);
octave:3>  r1 = chol(a);
 ** On entry to DPOTRF parameter number  4 had an illegal value
*** glibc detected *** /root/software/octave/hg/octave/src/.libs/octave:
double free or corruption (fasttop): 0x0000000002691d60 ***
======= Backtrace: =========
/lib/libc.so.6(+0x72f25)[0x7f566ea71f25]
/lib/libc.so.6(cfree+0x6c)[0x7f566ea76d9c]
//usr/lib64/opengl/nvidia/lib/libnvidia-tls.so.260.19.21(+0x8bb)[0x7f566e0c58bb]
======= Memory map: ========

<snip>

but

octave:1> n=100;
octave:2> a = 10*speye(n) + sparse(1:n,ceil([1:n]/2),1,n,n) + ...
>       sparse(ceil([1:n]/2),1:n,1,n,n);
octave:3> r1 = chol(a);
octave:4>

is ok. So changing line 37 in:
to
        otherimages (nm, 100, typ);

makes the dev sources build fine - I have no clue why that is.

/Fredrik