Some CDT DSF GDB tests failing on GitHub Actions #816

jonahgraham · 2024-06-05T17:21:55Z

At some point recently CDT's DSF GDB tests started having some failures on GitHub actions, specifically 8 errors, 60 fail. See for example this run https://github.com/eclipse-cdt/cdt/runs/25845154142

The text was updated successfully, but these errors were encountered:

jonahgraham · 2024-06-19T16:05:04Z

The "8 errors, 60 fail" is the known and expected failures at the moment.

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 executables lines between entry and area of interest. 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

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 executables lines between entry and area of interest. 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

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

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

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

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

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

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