Segfault in narrow band solvers p?gbtrf and p?dbtrs

Post here if you want to report a bug to the LAPACK team

Segfault in narrow band solvers p?gbtrf and p?dbtrs

Postby Sascha » Mon Mar 21, 2016 8:25 am

For the routine pzdbtrs, the workspace access will lead to a segfault because the leading dimension of the workspace is wrong. This error can be circumvented by allocating more workspace than required and reported. The correct way to fix it would probably be to adapt the leading dimension of the workspace in the following way:

Lines 1544-1553 of file pzdbtrsv.f

CALL ZLAMOV( 'N', BWU, NRHS, B( PART_OFFSET+ODD_SIZE+1), LLDB,
$ WORK( 1+MAX_BW-BWU ), MAX_BW )
*
CALL ZTRMM( 'L', 'L', 'N', 'N', BWU, NRHS, -CONE,
$ A(( OFST+1+ODD_SIZE*LLDA )), LLDA-1,
$ WORK( 1+MAX_BW-BWU ), MAX_BW )
*
CALL ZMATADD( BWU, NRHS, CONE, WORK( 1+MAX_BW-BWU ),
$ MAX_BW, CONE,
$ B( PART_OFFSET+ODD_SIZE-BWU+1 ), LLDB )

There is an error in pzgbtrf as well. The array ipiv is too short. In the steps of the divide and conquer
CALL ZGETRF(BM+BMN, BW, AF(BBPTR+BW*LDBB), LDBB,
$ IPIV(LN+1), INFO)
the function ZGETRF is called with a rest of IPIV that has the size BW in my case, which is correct because IPIV in ZGETRF needs to be the min of the dimensions.
But in the last step of the divide and conquer, line 1050-1051 of file pzgbtrf.f, it is called like this
CALL ZGETRF(BM+BMN,BM+BMN, AF(BBPTR+BW*LDBB), LDBB,
$ IPIV(LN+1), INFO)
Thus IPIV needs to have LN+BM+BMN integers and not only LN+BW, like in the case above, because ZGETRF writes on it. Even though this part seems not to be needed later on in the solving phase.
Sascha
 
Posts: 1
Joined: Mon Mar 21, 2016 8:06 am

Return to Bug report

Who is online

Users browsing this forum: No registered users and 2 guests