octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compiling development sources


From: Carlo de Falco
Subject: Re: compiling development sources
Date: Wed, 17 Feb 2010 08:28:36 +0100


On 16 Feb 2010, at 19:34, Carlo de Falco wrote:


On 11 Feb 2010, at 13:30, Jaroslav Hajek wrote:

On Thu, Feb 11, 2010 at 12:58 PM, Carlo de Falco
<address@hidden> wrote:

On 11 Feb 2010, at 12:50, Jaroslav Hajek wrote:

It's surely worth trying, although as I said, not a single line of
code in the library routines has changed since 1.1.0, it's just the
test suite, so in theory the binary should be identical to 1.1.0.
Compared to 1.0, only 8 new routines were added. If you start seeing the test failures in Octave again, try rebuilding and re-running the qrupdate test suite. For me, the manifestation of the bug seemed to be
dependent on previous calls to BLAS made, and it apparently made a
difference whether the BLAS remained in memory or not.
In any case, it will help if you discover which test was failing for you:
./run-octave
octave:1> test qr verbose

this should dump the tests as they're tried so you'll see which one
crashed.


As I mentioned in a previous post, I could reproduce the segfault in Octave
with the following test from the qrupdate testsuite:

Ac = [0.620405 + 0.956953i 0.480013 + 0.048806i 0.402627 + 0.338171i; 0.589077 + 0.658457i 0.013205 + 0.279323i 0.229284 + 0.721929i; 0.092758 + 0.345687i 0.928679 + 0.241052i 0.764536 + 0.832406i; 0.912098 + 0.721024i 0.049018 + 0.269452i 0.730029 + 0.796517i; 0.112849 + 0.603871i 0.486352 + 0.142337i 0.355646 + 0.151496i ];

uc = [0.20351 + 0.05401i;
   0.13141 + 0.43708i;
   0.29808 + 0.08789i;
   0.69821 + 0.38844i;
   0.74871 + 0.25821i ];

vc = [0.85839 + 0.29468i;
   0.20820 + 0.93090i;
   0.86184 + 0.34689i ];


[Q,R] = qr(Ac);
[Q,R] = qrupdate(Q,R,uc,vc);

and the result was

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x00000000
0x8fe18c02 in __dyld_misaligned_stack_error ()
(gdb)

a similar test with real data gives no problem.


I should have added that of course I tried this even with valgrind but
don't get any errors. I suspect your BLAS to be responsible.


Just an update about a curious fact I just noticed:
with my latest build attempt (using gcc4.2 and gfortran4.2) running in the debugger I get:

--------------------------------------------------------------------------------------------------------------------------------
./run-octave -g --silent --norc

octave:1> Ac = [0.620405 + 0.956953i 0.480013 + 0.048806i 0.402627 + 0.338171i; > 0.589077 + 0.658457i 0.013205 + 0.279323i 0.229284 + 0.721929i; > 0.092758 + 0.345687i 0.928679 + 0.241052i 0.764536 + 0.832406i; > 0.912098 + 0.721024i 0.049018 + 0.269452i 0.730029 + 0.796517i; > 0.112849 + 0.603871i 0.486352 + 0.142337i 0.355646 + 0.151496i ];
octave:2>
octave:2> uc = [0.20351 + 0.05401i;
>     0.13141 + 0.43708i;
>     0.29808 + 0.08789i;
>     0.69821 + 0.38844i;
>     0.74871 + 0.25821i ];
octave:3>
octave:3> vc = [0.85839 + 0.29468i;
>     0.20820 + 0.93090i;
>     0.86184 + 0.34689i ];
octave:4>
octave:4>
octave:4> [Q,R] = qr(Ac);
Reading symbols for shared libraries . done
octave:5> [Q,R] = qrupdate(Q,R,uc,vc);

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x00000000
0x8fe18c02 in __dyld_misaligned_stack_error ()
(gdb) bt
#0  0x8fe18c02 in __dyld_misaligned_stack_error ()
#1  0x00000014 in ?? ()
#2  0x031f3a49 in zqrtv1_ () at allocator.h:100
#3  0x031ef838 in zqr1up_ () at allocator.h:100
#4 0x02d38ec8 in ComplexQR::update (this=0xbffec8a0, address@hidden, address@hidden) at CmplxQR.cc:228 #5 0x00d79dbd in Fqrupdate (address@hidden) at DLD-FUNCTIONS/qr.cc: 867 #6 0x0187b70e in octave_builtin::do_multi_index_op (this=0x4055490, nargout=2, address@hidden) at ov-builtin.cc:107 #7 0x01879f49 in octave_builtin::subsref (this=0x4055490, address@hidden, address@hidden, nargout=2) at ov-builtin.cc:55 #8 0x019b09f3 in octave_value::subsref (this=0xbffecea0, address@hidden, address@hidden, nargout=2) at ov.cc:1189 #9 0x01ab11a0 in tree_index_expression::rvalue (this=0x3980a10, nargout=2) at pt-idx.cc:401 #10 0x01a89ad9 in tree_multi_assignment::rvalue (this=0x3980ab0) at pt-assign.cc:365 #11 0x01a8818a in tree_multi_assignment::rvalue1 (this=0x3980ab0, nargout=54451568) at pt-assign.cc:320 #12 0x01a9caeb in tree_evaluator::visit_statement (this=0x2405d80, address@hidden) at pt-eval.cc:718 #13 0x01a9e9ff in tree_evaluator::visit_statement_list (this=0x2405d80, address@hidden) at pt-eval.cc:754
#14 0x017ec3f9 in main_loop () at toplev.cc:575
#15 0x01775f21 in octave_main (argc=8, argv=0xbffed3f4, embedded=0) at octave.cc:868
#16 0x00001ff0 in main (argc=54451568, argv=0x33edd70) at main.c:35
--------------------------------------------------------------------------------------------------------------------------------

trying to use valgrind to get some more info, though, I do not get the crash, and the three asserts in the qrupdate test work!!

--------------------------------------------------------------------------------------------------------------------------------
octave:14> assert(norm(vec(Q'*Q - eye(5)),Inf) < 1e1*eps)
octave:15> assert(norm(vec(triu(R)-R),Inf) == 0)
octave:16> assert(norm(vec(Q*R - Ac - uc*vc'),Inf) < norm(Ac)*1e1*eps)
--------------------------------------------------------------------------------------------------------------------------------

any idea what might be going on??
c.

OK, I see now that this is a FAQ on the valgrind site:
http://valgrind.org/docs/manual/faq.html#faq.crashes
sorry for the noise...
c.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]