debugSymbolsSmokeGDB fails with latest Mandrel

[zakkak]

debugSymbolsSmokeGDB fails with latest Mandrel

The failure reports

[ERROR] Failures: 
[ERROR]   DebugSymbolsTest.debugSymbolsSmokeGDB:136->carryOutGDBSession:385 There were errors in the GDB session. Note that commands in the session might depend on each other. Errors: 
Command 'c' did not match the expected pattern '.*Breakpoint 3, debug_symbols_smoke.Main::main.*at debug_symbols_smoke/Main.java:76.*String l = sc.nextLine\(\);.*'.
Output was:
(gdb) Continuing.

Thread 1 "debug-symbols-s" hit Breakpoint 2, debug_symbols_smoke.Main::main(java.lang.String[] *) (args=<optimized out>) at debug_symbols_smoke/Main.java:71
71                  if (myString != null && myNumber != Integer.MIN_VALUE) {
, 
Command 'c' did not match the expected pattern '.*Breakpoint 2, debug_symbols_smoke.Main::main.*at debug_symbols_smoke/Main.java:71.* if \(myString != null.*'.
Output was:
(gdb) Continuing.

Thread 1 "debug-symbols-s" hit Breakpoint 3, debug_symbols_smoke.Main::main(java.lang.String[] *) (args=<optimized out>) at debug_symbols_smoke/Main.java:76
76                  String l = sc.nextLine();
, 
Command 'c' did not match the expected pattern '.*Breakpoint 2, debug_symbols_smoke.Main::main.*at debug_symbols_smoke/Main.java:71.* if \(myString != null.*'.
Output was:
(gdb) Continuing.
fdc7c50f390c145bc58a0bedbe5e6d2e35177ac73d12e2b23df149ce496a5572
[Thread 0x7ffff72ff640 (LWP 97902) exited]
[Inferior 1 (process 97901) exited normally]
, 
Command 'c' did not match the expected pattern '.*fdc7c50f390c145bc58a0bedbe5e6d2e35177ac73d12e2b23df149ce496a5572.*exited normally.*'.
Output was:
(gdb) (gdb) The program is not being run.
 ==> expected: <true> but was: <false>

Reproducer

1. Build mandrel from graal/master branch and add it to $GRAALVM_HOME and $PATH environment variables.
2. mvn clean verify -Dquarkus.version=999-SNAPSHOT -Ptestsuite -Dtest=DebugSymbolsTest#debugSymbolsSmokeGDB

Discussion

It looks like the current tests do not test a specific scenario that should always happen, as a result a potential optimization (e.g. Main.java:76 being executed earlier) could change the order of some instructions resulting on the test failure we are seeing. I think the test should use different breakpoints or check regexps to see if the breakpoints work as expected.

WDYT @Karm ?

[Karm]

@zakkak I think the time has proven the test too fragile :-( There must be a sweet spot between not catching an unexpected change in behavior and failing for weeks on what appears to be a false positive.

I will relax the regexp.

When it comes to choosing different breakpoints: Do you have any insight into why these are a bad choice? I chose them without giving it any more thought beyond what seemed useful at the moment.

[zakkak]

Do you have any insight into why these are a bad choice?

(After the fact insight): They turned out to be a bad choice because the compiler was allowed to reorder them as part of the optimizations it performs. As a result when choosing breakpoints we need to account for such potential optimizations (i.e., only expect a breakpoint to be reached after another if the corresponding lines have a dependency -- or some form of barrier -- forcing the ordering). Similarly we also need to be careful when it comes to dead code elimination and inlining. In general we should avoid checking for optimizations (or the lack of them) when running the gdb tests. Not sure how much it helps though since it's pretty hard to argue about some of these, but at least you can reduce the chances of future failures.

[zakkak]

This issue is no longer present. @Karm did you do anything to fix this or was it fixed by some upstream change that results in the old behavior?

[Karm]

@zakkak I haven't done anything in this particular area to fix this, so it is either an upstream change, or a gdb version change on updated Ubuntu or the worst case, it's intermittently flaky, racing...

[zakkak]

My best guess is that this was an upstream change (some compiler change that caused the reorderings and was later fixes or reverted).

[Karm]

Closing until we have the problem again.