Calling gges() function with a select functor results in memory corruption

Issue #300 resolved
Mikhail Katliar created an issue

Code:

static constexpr size_t N = 5;

blaze::StaticMatrix<double, N, N> A, B, VSL, VSR;
blaze::StaticVector<std::complex<double>, N> alpha;
blaze::StaticVector<double, N> beta;

randomize(A);
randomize(B);

const auto select = []( double const * alphar, double const * alphai, double const * beta ) -> bool {
    return pow(*alphar, 2) + pow(*alphai, 2) > pow(*beta, 2);
};

gges(A, B, VSL, alpha, beta, VSR, select);

valgrind shows one invalid write and several invalid reads of size 4.

The issue is not present without the select functor.

Comments (7)

  1. Mikhail Katliar reporter

    My guess is that the error is due to the fact that the Fortran LOGICAL type has different size than bool:

    LOGICAL

    The logical data type, LOGICAL, holds a logical value .TRUE. or .FALSE. The value 0 represents .FALSE.; any other value represents .TRUE.

    The usual default size for an LOGICAL item with no size specified is 4, and is aligned on 4-byte boundaries. However, these defaults can be changed by compiling with certain special options.

    https://docs.oracle.com/cd/E19957-01/805-4939/z40007365fe9/index.html

    The return type of the SELCTG function is specified as LOGICAL in Fortran. The type of the BWORK array is also LOGICAL.

  2. Klaus Iglberger

    Commit 4c58836 fixes the gges() LAPACK functions and resolves the valgrind issues. The fix is immediately available via cloning the Blaze repository and will be officially released in Blaze 3.7.

  3. Log in to comment