LAPACK Archives

[Lapack] lapack-3.2.0 : a bug in 'dlaqr3.f'

Hello Edouard,

[1] Thanks for the bug report. Yep, nicely done. Bug reproduced without
     any difficulty on my machine. The trick is to change:

     line 198-200 of dlaqr3.f

          CALL DORMHR( 'R', 'N', JW, JW, 1, JW-1, T, LDT, WORK, V, LDV,
      $                WORK( JW+1 ), -1, INFO )
          LWK2 = INT( WORK( JW+1 ) )

     with line 198-200 de dlaqr3.f

          CALL DORMHR( 'R', 'N', JW, JW, 1, JW-1, T, LDT, WORK, V, LDV,
      $                WORK( 1 ), -1, INFO )
          LWK2 = INT( WORK( 1 ) )

     Then valgrind is happy :).

[2] Edward Smyth (NAG) also worked on it. (Same fix.) He chekced that the
     bug was indeed in [S,D,C,Z]LAQR3 and [S,D,C,Z]LAQR2. Ed will
     commit the fix in the SVN. Thanks Ed!

[3] I just want to note that workspace query are NOT checked at all in
     the LAPACK TESTING. We need to rewrite these testing!!!! (OK this has
     been in the TODO list for several years now ... )

[4] I propose a release today or tomorrow:
     either lapack- (I prefer) or lapack-3.2.1 or whatever

Best wishes,

On Tue, 2 Dec 2008, ?douard Canot wrote:

[Bonjour Julie, encore un bug trouv? dans la derni?re version de Lapack]

I'm working with the SCHUR decomposition and I want to query the optimal size
for the allocatable WORK(:) array. So, I call the DGEES routine with LWORK=-1,
in order to get the required size in WORK(1).
I'm calling this routine with a matrix of shape (12,12) so that it is greater 
the threshold NTINY=11 seen in DGEES (or someelse routine).

When using lapack-3.1, it was sufficient to first allocate the WORK(:) array 
with size=1,
retrieve the optimal size in WORK(1), then reallocate it with the good size.

Indeed, the DGEES documentation says that WORK(:) must have its dimension 
to MAX(1,LWORK)). So, when a query is done, a size of 1 should be ok; and 
it does.

With lapack-3.2, the same process leads sometimes to a seg. fault, which is 
when using valgrind :
==26256== Invalid write of size 8
==26256==    at 0x875A9B2: dormhr_ (dormhr.f:164)
==26256==    by 0x874A1BA: dlaqr3_ (dlaqr3.f:199)
==26256==    by 0x8748AAC: dlaqr0_ (dlaqr0.f:286)
==26256==    by 0x87419D3: dhseqr_ (dhseqr.f:315)
==26256==    by 0x872BF0E: dgees_ (dgees.f:206)

The problem occurs with three different compilers, so I have investigated it, 
and I found
that DLAQR3 calls now DORMHR (and not DORGHR as before). It is due to embedded
On line 199 of 'dormhr.f', there is a query for an optimal size, using 
WORK(JW+1), with
JW+1 = 4, so an invalid write occurs, which sometimes leads to the above 
seg. fault.
If the coding of DORMHR cannot be changed, then the documentation of DGEES 
be fixed, and must note that the size of WORK(:) must be greater than, ... 
hum, N ?

By the way, there are many files ('dhseqr.f', 'dlaqr0.f', 'dlaqr3.f' and 
perhaps others) which
have been modified : they are tagged with the correct version (lapack 3.2) 
but are
dated 'november 2006'; this should be changed to 'november 2008', isn't it ?

?douard CANOT
Lapack mailing list

<Prev in Thread] Current Thread [Next in Thread>

For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or