Rsytrd.test_double fails

[DavidC-75]

Hi,

I've just built mplapack 2.0.1 from scratch (on Suse Linux Enterprise 12), and Rsytrd.test_double fails (all other tests for all other possible formats are passing)

make Rsytrd.test_double.log
../../../../test-driver: line 107: 28353 Segmentation fault      (core dumped) "$@" > $log_file 2>&1
FAIL: Rsytrd.test_double

I tried a few different things:

• buiding with gcc 10.2.0
• building with gcc 9.3.0
• cross-compiling for Windows64 (using this MXE version)

and it consistently fails.
Running natively on Windows or on Linux via wine also fails.

Running via wine shows some possibly relevant details (but I'm not really skilled enough to know....)

Unhandled exception: page fault on read access to 0xffffffffffffffff in 64-bit code (0x00000352005095).
Backtrace:
=>0 0x00000352005095 in libmpfr-6 (+0x95095) (0x8000000000000000)
  1 0x00000140e9e3a1 in rsytrd.test_double (+0xe9e3a1) (0x00000352004f00)
  2 0x00000140e9cdb4 in rsytrd.test_double (+0xe9cdb4) (0x00000000000002)
  3 0x00000140eb667d in rsytrd.test_double (+0xeb667d) (0000000000000000)

It's quite obscure to me why MPFR would be involved at all in this test, since it's a native 'double' test and not really a multi-precision tests.
However I also tried upgrading the built-in MPFR 4.1.0-p13 to MPFR 4.2.0-p9 and it still fails in the same way.

Can anyone reproduce ? I have unfortunately no idea how to go about debugging this....

[nakatamaho]

Hmm, I don't know why it fails. These tests are not mandatory, and they may not be serious.

It's quite obscure to me why MPFR would be involved at all in this test since it's a native 'double' test and not really a multi-precision test.
Yes, we need MPFR, since we compare the MPFR version and double version of MPBLAS, and if the differences are small, we expect that the double version is correctly implemented. See section 8 of https://arxiv.org/pdf/2109.13406.pdf for details. If the LIN or EIG tests fail, errors can be serious.

[DavidC-75]

Hmm, I don't know why it fails. These tests are not mandatory, and they may not be serious.

Well maybe my report didn't emphasize enough on one aspect: the test just doesn't fail, it crashes (Segmentation fault).
To me it suggests something quite serious. In any case, my personal view is that any failure is worth investigating. If some failures are deemed "possibly not serious" then what's the point of writing tests in the first place ?

Can you reproduce my observations ?

Having said that, don't get me wrong: I am hugely appreciative of all the work you've done to make this multi-precision library available. It's very early days for me and I have a lot to explore and to learn !

[nakatamaho]

Thanks, and you have a reason. And I couldn't reproduce it.

I used Docker_fable to reproduce the result. Such an error occurred when the wine setup is something went wrong
or WINEPATH is not appropriately set.
(note that my WINEPATH is the following:
WINEPATH="/usr/x86_64-w64-mingw32/lib/;/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/;/usr/lib/gcc/x86_64-w64-mingw32/9.3-posix"

How about other tests? like
$ wine64 x86_64-w64-mingw32-Rlamch.test_double.exe
*** Testing Rlamch start ***
Rlamch E: Epsilon +1.1102230246251565e-16
Rlamch S: Safe minimum +2.2250738585072014e-308
Rlamch B: Base +2.0000000000000000e+00
Rlamch P: Precision +2.2204460492503131e-16
Rlamch N: Number of digits in mantissa +5.3000000000000000e+01
Rlamch R: Rounding mode +1.0000000000000000e+00
Rlamch M: Minimum exponent: -1.0210000000000000e+03
Rlamch U: Underflow threshold +2.2250738585072014e-308
Rlamch L: Largest exponent +1.0240000000000000e+03
Rlamch O: Overflow threshold +1.7976931348623157e+308
Rlamch -: Reciprocal of safe minimum +4.4942328371557898e+307
Rlamch Z: dummy (error) +0.0000000000000000e+00
*** Testing Rlamch successful ***

Best regards

[DavidC-75]

Wine is (at first sight) not the cause of the problems. I have configured WINEPATH correctly so it picks up the necessary run-time libraries.
Just to clarify my initial report, I observe the same crash of Rsytrd.test_double whether I run:

• the Linux executable under Linux
• the Windows executable under Linux via wine64
• the Windows executable under Windows directly

Besides, as I mentioned in my initial report:

all other tests for all other possible formats are passing
(by format, I mean dd, qd, mpfr, gmp, etc...)

What I find suspicious, is that the test crashes both when compiled for Linux and when compiled for Windows. This is not a definitive proof, but suggests that it's not a tool-related issue, but perhaps a genuine issue in the mplapack library or in the test itself ?