Closed zakkak closed 2 years ago
@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.
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.
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?
@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...
My best guess is that this was an upstream change (some compiler change that caused the reorderings and was later fixes or reverted).
Closing until we have the problem again.
debugSymbolsSmokeGDB fails with latest Mandrel
The failure reports
Reproducer
graal/master
branch and add it to$GRAALVM_HOME
and$PATH
environment variables.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 ?