Bug#693269: Bug #693269: liblapack-dev: Some routines produce incorrect results in multithreaded environment

[Michael Banck]

tags 693269 +patch
severity 693269 important
thanks

On Wed, Nov 14, 2012 at 02:14:53PM -0800, Victor Liu wrote:
> When writing code that uses Lapack as well as threads (pthreads or OpenMP),
> certain routines, like the nonsymmetric eigensolver, produce incorrect results
> due to statically allocated arrays. 

Thanks for filing the bug, I bumped into this last week while packaging
elk (ITP #706538).  I was puzzled at first as elk ships its own set of
blas/lapack routines, and when linking them in, its test suites runs
fine.  However, patching them out and linking to the Debian-provided
blas and lapack libraries resulted in random but significant numerical
errors.

It turned out that elk unconditionally adds -fopenmp to its FFLAGS, so
the blas/lapack routines were compiled like this as well.  This
apparently works around the bug, however, it is probably not the best
(if any) fix.

> The Lapack source uses large local arrays which are deemed by gfortran
> (by default) to be too large to allocate on the stack, leading to
> statically allocated variables which are corrupted when multiple
> threads write to them. Adding the "-frecursive" flag to the
> compilation flags would force gfortran to always allocate the arrays
> on the stack. 

I discussed this with one of the maintainers on IRC this weekend and
they preferred to declare only the problematic routines as RECURSIVE.

> The problem along with code to reproduce it has been listed in this
> forum post:
> http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1930

Thanks for your(?) work in
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1930#p9928 I
created a patch which makes all the subroutines with large local arrays
RECURSIVE.  I can confirm that this fixes the problem for the case of
elk.

I keep the severity at "important" for now, but I consider this a
serious bug which should get fixed in the first squeeze point release.


Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recursive.patch
Type: text/x-diff
Size: 21490 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20130506/a20aeffc/attachment-0001.patch>