Bug in octave 3.2.x with custom atlas multithread

Fri Jul 3 05:57:16 CDT 2009

Dear jaroslav Hajek,

this is the valgrind report

==7393== 
==7393== Invalid read of size 8
==7393==    at 0x6001F0E: Array<std::complex<double> >::operator=(Array<std::complex<double> > const&) (in /home/corradin/d1/packaging/octave-3.2.1/liboctave/liboctave.so)
==7393==    by 0x15483C1D: EIG::operator=(EIG const&) (in /home/corradin/d1/packaging/octave-3.2.1/src/eig.oct)
==7393==    by 0x15482991: Feig(octave_value_list const&, int) (in /home/corradin/d1/packaging/octave-3.2.1/src/eig.oct)
==7393==    by 0x54A645E: octave_builtin::do_multi_index_op(int, octave_value_list const&) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x54A5DF2: octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x545D7EF: octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x5579C89: tree_index_expression::rvalue(int) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x555E87D: tree_multi_assignment::rvalue(int) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x555E4FD: tree_multi_assignment::rvalue1(int) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x556B813: tree_evaluator::visit_statement(tree_statement&) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x5569E02: tree_evaluator::visit_statement_list(tree_statement_list&) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==    by 0x556D195: tree_evaluator::visit_simple_for_command(tree_simple_for_command&) (in /home/corradin/d1/packaging/octave-3.2.1/src/liboctinterp.so)
==7393==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
panic: Segmentation fault -- stopping myself...
Thinking... please wait a moment...
(5/5) Complex matrix operations     
Loop
 1
of
 10
attempting to save variables to `octave-core'...
save to `octave-core' complete
==7393== 
==7393== ERROR SUMMARY: 39 errors from 7 contexts (suppressed: 131 from 3)
==7393== malloc/free: in use at exit: 82,307,044 bytes in 80,440 blocks.
==7393== malloc/free: 871,667 allocs, 791,227 frees, 763,233,387 bytes allocated.
==7393== For counts of detected errors, rerun with: -v
==7393== searching for pointers to 80,440 not-freed blocks.
==7393== checked 47,158,088 bytes.
==7393== 
==7393== LEAK SUMMARY:
==7393==    definitely lost: 44,547 bytes in 101 blocks.
==7393==      possibly lost: 1,146,398 bytes in 22,253 blocks.
==7393==    still reachable: 81,116,099 bytes in 58,086 blocks.
==7393==         suppressed: 0 bytes in 0 blocks.
==7393== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault

Now I am also trying to recomplie octave with lapack at the end of with-blas =" ... -llpack"
Bests
Riccardo Corradini
--- Ven 3/7/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:

Da: Jaroslav Hajek <highegg at gmail.com>
Oggetto: Re: Bug in octave 3.2.x with custom atlas multithread
A: "Riccardo Corradini" <riccardocorradini at yahoo.it>
Cc: bug at octave.org
Data: Venerdì 3 luglio 2009, 11:23

On Fri, Jul 3, 2009 at 10:34 AM, Riccardo
Corradini<riccardocorradini at yahoo.it> wrote:
> Dear stuff,
> this is the bug report
>
> Subject: obench.m crashes with octave3.2.x multithreaded
> --------
> Bug report for Octave 3.2.1 configured for x86_64-unknown-linux-gnu
>
> Description:
> -----------
>
>   when I run the file obench.m available at
> http://www.reimeika.ca/marco/obench
> it crashes during complex operations
> Repeat-By:
> ---------
>
> I think there are problems with Fortran complex numbers libs
> NB : the make check gives no errors ( 0 FAILS)
> Fix:

It works for me, also on x86_64 (Core 2 Duo) Linux with GCC and
GotoBLAS on both -O3 -march=native and -O0 -g, and also with Intel
C++/Fortran and the multithreaded ACML library. I therefore suspect a
problem in your configuration, possibly miscompiled ATLAS (?). To
proceed further, I suggest you isolate the failure as narrowly as you
can, and run Octave with valgrind (when compiled, you can use
./run-octave -valgrind in the build dir) to find out whether the fault
occurs inside ATLAS or elsewhere.

Btw., I think -llapack should be specified *after* ATLAS, because
ATLAS optimizes some LAPACK subroutines and in this manner you
probably link to the unoptimized ones from within Octave. It may also
be the source of the crash, but I wouldn't bet on it.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090703/556e85c2/attachment.html 