Fix flaky/broken DSF GDB tests #985
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b9be266 to
751e040
Compare
a1c52b0 to
d82d4e1
Compare
1f39b7d to
96c567d
Compare
The combination of gcc 9.4 and gdb 9.2 in Ubuntu 20.04 have a few minor test issues that seem to be bugs in gdb that have been since fixed. Part of eclipse-cdt#816
The tests were relying on specific number of executable lines
in a function. However on some gdb/gcc combinations stopping
at a function stops at the line with the `{` and some
on the first line witin that function. Much of the tests
here assumed that latter. By using line tags we don't need
to worry about exact number of executable lines between entry
and area of interest. And by placing first line of code on
the same line as the opening `{` of the function, we can
have consistent stop locations when stepping into a function.
Part of eclipse-cdt#816
Without the return, this code would core dump, depending on compiler version. The compiler was generating a warning too about the missing return. Part of eclipse-cdt#816
From GDB news: print Printing of floating-point values with base-modifying formats like /x has been changed to display the underlying bytes of the value in the desired base. This was GDB's documented behavior, but was never implemented correctly. This commit updates the tests to accomodate GDB's change. Fixes eclipse-cdt#210
This test sometimes hangs when run a lot. As best as I can tell this is a Ubuntu problem, rather than a gdb problem as it only fails on Ubuntu 24.04, but I am not sure. I cannot reproduce the problem when using the UI. Part of eclipse-cdt#816
"script" field of a breakpoint used to be output as a tuple (<= GDB 12), though it is a list. There are cases of flags that can be applied to get old or new behaviour too. This code handles both cases transparently. See https://sourceware.org/bugzilla/show_bug.cgi?id=24285 Part of eclipse-cdt#816
We should explicitly set the version of mi to use. Until recently mi == mi2, but with the recent introduction of mi3 as the default we need to be explicit. The other place that specifies interpreter is explicit about version and includes an important comment on the subject https://github.com/eclipse-cdt/cdt/blob/1590791e76a58ead4d2d7481a5e9a0ff5f83dfab/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBBackend.java#L189-L191 Part of eclipse-cdt#816
On GitHub I see fails in resume[gdb] (org.eclipse.cdt.tests.dsf.gdb.tests.MIRunControlTest) with this output: ``` Terminate failed org.eclipse.debug.core.DebugException: Terminate failed at org.eclipse.debug.core.Launch.terminate(Launch.java:300) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunch.terminate(GdbLaunch.java:313) at org.eclipse.cdt.tests.dsf.gdb.framework.BaseTestCase.doAfterTest(BaseTestCase.java:662) at org.eclipse.cdt.tests.dsf.gdb.tests.MIRunControlTest.doAfterTest(MIRunControlTest.java:133) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.lang.Thread.run(Thread.java:1583) Contains: Terminate failed Contains: Terminate failed 790,475 "resume[gdb]" requesting gdb. Launched gdb 15.0.50.20240403. ``` which is insufficient to diagnose what is happening. Part of eclipse-cdt#816
The DSF-GDB tests themselves can take an hour or so. Part of eclipse-cdt#816
This will try to rerun failed tests up to three times. The side effect is that a very broken test run will take much longer to complete, but it is hoped for those few https://github.com/eclipse-cdt/cdt/labels/flakytests in the system this will resolve the issue. Note this is applied only to the GitHub actions run, not to Jenkins run where we build releases from. Ideally we don't want to do that there. In a future commit we can consider removing flakyTest from -DexcludedGroups too. See [surefire docs](https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html) for details.
96c567d to
3f1b0f2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #816