[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave 3.3.54 snapshot available for ftp
From: |
Fredrik Lingvall |
Subject: |
Re: Octave 3.3.54 snapshot available for ftp |
Date: |
Tue, 23 Nov 2010 18:42:42 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101105 Lightning/1.0b3pre Thunderbird/3.1.6 |
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
- Re: Octave 3.3.54 snapshot available for ftp, (continued)
Re: Octave 3.3.54 snapshot available for ftp, Fredrik Lingvall, 2010/11/21
- Re: Octave 3.3.54 snapshot available for ftp, John W. Eaton, 2010/11/22
- Re: Octave 3.3.54 snapshot available for ftp, Fredrik Lingvall, 2010/11/22
- Re: Octave 3.3.54 snapshot available for ftp, Fredrik Lingvall, 2010/11/22
- Re: Octave 3.3.54 snapshot available for ftp, John W. Eaton, 2010/11/22
- Re: Octave 3.3.54 snapshot available for ftp, Fredrik Lingvall, 2010/11/23
- Re: Octave 3.3.54 snapshot available for ftp, John W. Eaton, 2010/11/23
- Re: Octave 3.3.54 snapshot available for ftp, Fredrik Lingvall, 2010/11/23
- Re: Octave 3.3.54 snapshot available for ftp,
Fredrik Lingvall <=