On Mon, May 7, 2012 at 3:16 AM, Alexander Grayver <span dir="ltr"><<a href="mailto:agrayver@gfz-potsdam.de" target="_blank">agrayver@gfz-potsdam.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06.05.2012 22:24, Barry Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alexander,<br>
<br>
I cannot reproduce this on my mac with 3 different blas/lapack.<br>
</blockquote>
<br>
Barry,<br>
<br>
I'm surprised. I ran it on my home PC with ubuntu and PETSc configured from scratch as following:<br>
--download-mpich --with-fortran-interfaces=1 --download-scalapack --download-blacs --with-scalar-type=complex --download-blas-lapack --with-precision=double<br>
<br>
And it's still there.<br>
Please note that all my numbers are complex.<br></blockquote><div><br></div><div>I just ran this with complex instead of real. I get </div><div><br></div><div><div>sh: 1.688716e+00 </div></div><div><br></div><div>and no crash.</div>
<div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could you please run the case below but with --download-f-blas-lapack (you forgot the -f last time)? Send us the valgrind results. This will tell use the exact line number in dlasq3() that is triggering the bad read.<br>
</blockquote>
<br>
I did:<br>
./configure --with-petsc-arch=openmpi-<u></u>intel-complex-debug-c --download-scalapack --download-blacs --download-f-blas-lapack --with-precision=double --with-scalar-type=complex<br>
<br>
And then valgrind program. The first message from log:<br>
<br>
==27656== Invalid write of size 8<br>
==27656== at 0x15A8E9E: dlasq2_ (dlasq2.f:215)<br>
==27656== by 0x15A83A4: dlasq1_ (dlasq1.f:135)<br>
==27656== by 0x158ACEC: zbdsqr_ (zbdsqr.f:225)<br>
==27656== by 0x154EC27: zgesvd_ (zgesvd.f:2038)<br>
==27656== by 0x695DD3: KSPComputeExtremeSingularValue<u></u>s_GMRES (gmreig.c:46)<br>
==27656== by 0x69DD76: KSPComputeExtremeSingularValue<u></u>s (itfunc.c:47)<br>
==27656== by 0x44E98C: main (solveTest.c:62)<br>
==27656== Address 0xfad2d98 is 8 bytes before a block of size 832 alloc'd<br>
==27656== at 0x4C25D66: memalign (vg_replace_malloc.c:694)<br>
==27656== by 0x4B642B: PetscMallocAlign (mal.c:30)<br>
==27656== by 0x687775: KSPSetUp_GMRES (gmres.c:73)<br>
==27656== by 0x69FE4A: KSPSetUp (itfunc.c:239)<br>
==27656== by 0x6A2058: KSPSolve (itfunc.c:402)<br>
==27656== by 0x44E969: main (solveTest.c:61)<br>
<br>
Please find full log attached.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Barry<br>
<br>
<br>
On May 6, 2012, at 9:16 AM, Alexander Grayver wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06.05.2012 15:34, Matthew Knepley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, May 6, 2012 at 9:24 AM, Alexander Grayver<<a href="mailto:agrayver@gfz-potsdam.de" target="_blank">agrayver@gfz-potsdam.<u></u>de</a>> wrote:<br>
Hm, valgrind gives a lot of output like that (see full log in previous message):<br>
<br>
Can you run this with --download-f-blas-lapack? This sounds much more like an MKL bug.<br>
</blockquote>
I did:<br>
--download-scalapack --download-blacs --download-blas-lapack --with-precision=double --with-scalar-type=complex<br>
<br>
The error is still there. I checked "ldd solveTest", mkl is not used for sure. This is not an MKL problem I guess:<br>
<br>
==13600== Invalid read of size 8<br>
==13600== at 0x58636AF: dlasq3_ (in /usr/local/lib/liblapack.so.3.<u></u>2.2)<br>
==13600== by 0x5862C84: dlasq2_ (in /usr/local/lib/liblapack.so.3.<u></u>2.2)<br>
==13600== by 0x5861F2C: dlasq1_ (in /usr/local/lib/liblapack.so.3.<u></u>2.2)<br>
==13600== by 0x571A479: zbdsqr_ (in /usr/local/lib/liblapack.so.3.<u></u>2.2)<br>
==13600== by 0x57466A7: zgesvd_ (in /usr/local/lib/liblapack.so.3.<u></u>2.2)<br>
==13600== by 0x694687: KSPComputeExtremeSingularValue<u></u>s_GMRES (gmreig.c:46)<br>
==13600== by 0x69C62A: KSPComputeExtremeSingularValue<u></u>s (itfunc.c:47)<br>
==13600== by 0x44E02C: main (solveTest.c:62)<br>
==13600== Address 0x10826b90 is 16 bytes before a block of size 832 alloc'd<br>
==13600== at 0x4C25D66: memalign (vg_replace_malloc.c:694)<br>
==13600== by 0x4B5ACB: PetscMallocAlign (mal.c:30)<br>
==13600== by 0x686181: KSPSetUp_GMRES (gmres.c:73)<br>
==13600== by 0x69E6FE: KSPSetUp (itfunc.c:239)<br>
==13600== by 0x6A090C: KSPSolve (itfunc.c:402)<br>
==13600== by 0x44E009: main (solveTest.c:61)<br>
<br>
The weird thing is that the it gives correct result, so zgesvd works fine.<br>
<br>
And also running this program with 10 iterations in valgrind doesn't produce error. The low above is with 100 iterations.<br>
Without valgrind the error is always there.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Regards,<br>
Alexander<br>
<br>
</font></span></blockquote></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Regards,<br>
Alexander<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>