Bug 186871 - Lapack xGELSD problem
Lapack xGELSD problem
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: lapack (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-27 01:45 EST by Jaroslav Hajek
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 3.1.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-21 23:44:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
two sources and a data file packed (4.16 KB, application/x-compressed-tar)
2006-03-27 01:45 EST, Jaroslav Hajek
no flags Details

  None (edit)
Description Jaroslav Hajek 2006-03-27 01:45:58 EST
Description of problem:

The lapack subroutines xGELSD (I tested single and double real, actually)
apparently calculate required real workspace incorrectly. The attached f90
program compiled with Fedora blas & lapack crashes with both ifort and gfortran,
but works when used with Intel's MKL lapack library. 

Version-Release number of selected component (if applicable):
 3.0-37.fc4 

How reproducible:
Attachment + Fortran 95 compilers (Intel ifort or gcc gfortran)

Steps to Reproduce:
1. unpack attachment
2 [details]. gfortran svd.f90 lapfail.f90 -lblas -llapack
3. ./a.out
  
Actual results:
           2         140          40           5
*** glibc detected *** ./a.out: double free or corruption (out): 0x09875fc8 ***
======= Backtrace: =========
/lib/libc.so.6[0x199124]
/lib/libc.so.6(__libc_free+0x77)[0x19965f]
/usr/lib/libgfortran.so.0(_gfortran_internal_free+0x42)[0xcf6aaf]
/usr/lib/libgfortran.so.0(_gfortran_deallocate+0x2c)[0xcf6be6]
./a.out[0x8049566]
./a.out[0x8049d22]
./a.out[0x8049e2b]
/lib/libc.so.6(__libc_start_main+0xdf)[0x14ad5f]
./a.out[0x8048a51]
======= Memory map: ========
00111000-00134000 r-xp 00000000 fd:00 7668788    /lib/libm-2.3.5.so
00134000-00135000 r-xp 00022000 fd:00 7668788    /lib/libm-2.3.5.so
00135000-00136000 rwxp 00023000 fd:00 7668788    /lib/libm-2.3.5.so
00136000-00259000 r-xp 00000000 fd:00 7668784    /lib/libc-2.3.5.so
00259000-0025b000 r-xp 00123000 fd:00 7668784    /lib/libc-2.3.5.so
0025b000-0025d000 rwxp 00125000 fd:00 7668784    /lib/libc-2.3.5.so
0025d000-0025f000 rwxp 0025d000 00:00 0
0051c000-00536000 r-xp 00000000 fd:00 7667762    /lib/ld-2.3.5.so
00536000-00537000 r-xp 00019000 fd:00 7667762    /lib/ld-2.3.5.so
00537000-00538000 rwxp 0001a000 fd:00 7667762    /lib/ld-2.3.5.so
00602000-009b3000 r-xp 00000000 fd:00 6432627    /usr/lib/liblapack.so.3.0.3
009b3000-009b6000 rwxp 003b1000 fd:00 6432627    /usr/lib/liblapack.so.3.0.3
009b6000-00aba000 rwxp 009b6000 00:00 0
00bf2000-00c49000 r-xp 00000000 fd:00 6425580    /usr/lib/libblas.so.3.0.3
00c49000-00c4a000 rwxp 00056000 fd:00 6425580    /usr/lib/libblas.so.3.0.3
00cee000-00d48000 r-xp 00000000 fd:00 6432729    /usr/lib/libgfortran.so.0.0.0
00d48000-00d49000 rwxp 00059000 fd:00 6432729    /usr/lib/libgfortran.so.0.0.0
00d49000-00d4d000 rwxp 00d49000 00:00 0
00db7000-00dc0000 r-xp 00000000 fd:00 7668789    /lib/libgcc_s-4.0.2-20051126.so.1
00dc0000-00dc1000 rwxp 00009000 fd:00 7668789    /lib/libgcc_s-4.0.2-20051126.so.1
00ea4000-00ea5000 r-xp 00ea4000 00:00 0          [vdso]
08048000-0804a000 r-xp 00000000 fd:00 4588980    /home/hajek/scratch/a.out
0804a000-0804b000 rw-p 00002000 fd:00 4588980    /home/hajek/scratch/a.out
09868000-09889000 rw-p 09868000 00:00 0          [heap]
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f9d000-b7f9f000 rw-p b7f9d000 00:00 0
b7fad000-b7fae000 rw-p b7fad000 00:00 0
bfa99000-bfaae000 rw-p bfa99000 00:00 0          [stack]
Aborted


Expected results:
           2         140          40           5

Additional info:
This bug seems to be closely related with #169399, however, that one 
is reported fixed and the author complained that he didn't succeed with
calculating the workspace size according to the subroutine description, whereas
I used the recommended and safer LWORK = -1 query to let the subroutine
calculate the workspace. The bug occurs often, but not for arbitrary matrices;
therefore, I attached a data file also, but I always succeded even with
initializing the matrices randomly.
Comment 1 Jaroslav Hajek 2006-03-27 01:45:58 EST
Created attachment 126793 [details]
two sources and a data file packed
Comment 2 Tom "spot" Callaway 2006-04-06 21:05:19 EDT
When I pass LWORK = -1, it doesn't segfault on me, but the calculated LWORK
value that your code uses for its sgelsd call shouldn't cause this.

I've asked the upstream LAPACK maintainer for advice on this one.
Comment 3 Tom "spot" Callaway 2006-09-14 14:50:16 EDT
Just as an addendum, I don't know exactly why this is failing. I tried to
backport some changes from LAPACK3E, but it did not resolve the issue (and
LAPACK3E does some things that make it unfriendly to Linux/gcc).

I'll leave this open, but barring upstream showing an interest in this, I doubt
it will go anywhere anytime soon.
Comment 4 Tom "spot" Callaway 2006-12-21 23:44:59 EST
LAPACK 3.1 resolves this case, it doesn't fail anymore. :) Please reopen if you
can reproduce, I used your attached test case to confirm that it doesn't fail
for me.

Note You need to log in before you can comment on or make changes to this bug.