Test slepc/step-36_parallel_02: very rare test failures

[tamiko]

[start automated regression testsuite report]

Dear all,

this is the automated regression testsuite reporting a new regression between

• new revision: 34ae3d3 regression testsuite results
• old revision: db38f30 regression testsuite results

Summary:

• 😠 new test failures introduced for configuration GNU-12.3.0-master-debian-13 on site tester-tng

I have identified the following pull requests as possible candidates:

• Check for ArborX C++20 bug #15757 (authored-by: @masterleinad; merged-by: @tamiko)

Notes:

• The regression reported above is a subset of the following full set of regressions compared to the baseline:
  • 😠 test failures for configuration GNU-12.3.0-master-debian-13 on site tester-tng
• I will close and unpin this issue automatically once a full run is complete and compares cleanly to the baseline.
• If closed I will reopen the issue if the testsuite run identified an additional regression compared to what I have reported so far.

[end automated regression testsuite report]

[masterleinad]

It seems very unlikely that #15757 causes a SLEPc test to fail.

[tamiko]

@masterleinad The configuration in question doesn't even have ArborX installed. There was also no change in userland (I didn't upgrade anything). It seems that one of the solvers just randomly returned a slightly different spectrum.

But there is literally no code change between the current and previous run. So if this is really a random failure mode then we're talking about a rate of 1 in 1000 or less.

Rerunning the test configuration in question...

[tamiko]

@masterleinad And sure enough - rerunning the test and it succeeds. I will try to "reproduce" in a quiet minute sometime this week which will be tricky. My best guess is some undefined behavior condition within slepcs + just the right scheduling of the tasks on cores. Maybe UBSAN can shed some light.