« Return to Thread: Bug in octave 3.2.x with custom atlas multithread

Re: Bug in octave 3.2.x with custom atlas multithread

by Jaroslav Hajek-2 :: Rate this Message:

Reply to Author | View in Thread

On Fri, Jul 3, 2009 at 12:57 PM, Riccardo
Corradini<riccardocorradini@...> wrote:

> 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
>

Is this the first error block? (or the first after the initial Octave
prompt, because readline initialization is known to generate false
alerts from valgrind)
There's almost surely nothing wrong in the Array<T>::operator= (it is
very simple), neither in EIG::operator= so the error has probably
happened earlier. Invalid memory writes often behave this weird.

Where does your ATLAS and LAPACK come from? Did you compile it on your own?


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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

 « Return to Thread: Bug in octave 3.2.x with custom atlas multithread