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 #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 #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#210
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 #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 #816
- Fix links for cdt-infra
- The cdt-infra git repo is now archived, so this commit updates
the links to the current values.
- Add new Docker related files to the gitattributes as text files
- Update DEFAULT_BUFFER_SIZE for Java 21's value when building JNI,
this also means the dll/exe need a rebuild
- add a toolchains.xml since we use Java 21 toolchain, but most bundles
are Java 17 still
* remove invalid tycho resolver config (not valid since many versions)
* fix PMD plugin configuration (config attribute was renamed in 3.18)
* remove duplicate versions already managed in pluginManagement section
* fix indentation
* move all not yet configured versions into pluginManagement of the
parent module to avoid further duplication
* consume the target platform as file, not as maven artifact (this
simplifies building a single module A LOT)
* remove invalid tycho-source-plugin configuration
* disable tycho consumer POM generation (not needed here, and avoids a
warning in each module)
* remove prerequisites. that's for maven plugins only, and this POM
already contains the better suited similar maven enforcer rule
* enforce UTF-8 for javadoc generation (the build fails on Windows
otherwise, trying to read some Japanese? characters with the Windows
default encoding)
Some bundles are bumped because dev happened between 11.2 release and
this version bump. The most significant change that happened
was the bump in Tycho version which changed ECJ version and
hence some class files changed
Part of #420
Looking at the logs, it seems that the regression is caused at 8bec791
where support for multi-process was added. We removed breakpoints
tracking support from final launch sequence and moved it to debug new
process and attach to process logic but none of these are run for remote
attach launch, hence breakpoint tracking is not started for remote
attach launch.
To fix the problem, IGDBProcesses.attachDebuggerToProcess(..) is updated
to handle remote attach launch as well instead of final launch sequence
handling it.
This commit is created after reverting 7bddb5f and 96839a0 which is the
older fix done to fix this issue and the other commit was to fix the
regression caused by the old fix.
The problem with older fix was that for non-stop mode, attach to process
was not working for remote launches when there is already a process
being debugged. Note that to use this feature, gdbserver should be
started with --multi option.
* Revert "Bug 580259: Not all remote session have a connected process"
This reverts commit 96839a029d.
* Revert "Bug 528145 - Attach debugger to a gdbserver remote session"
This reverts commit 7bddb5f4cb.
Note that FileBasedErrorParserTests had to change because of some
Tycho incompatibility with JUnit's ParameterizedTest. It works
in the IDE, but not in maven.
The correct fix is to resolve the tycho settings, see Bug 569949
for a previous example. It may also be simply resolved by updating
to Tycho 3.0.0. However I want to get this change in as
at the moment CDT.setup is broken and that is impeding developers.
These tests all had the same mistake, they had 5 x waitForEvent
with the comment "at this point all 5 threads should be stopped"
but there are actually 6 threads (5 spawned ones + main thread).
Most of the time all 6 threads would be stopped in time, but
sometimes one of them wouldn't be stopped, leading to a
"CoreException: Context is running" error in the test
This fixes the ThreadStackFrameSyncTest item
Part of #117
Warning in build.properties will be errors when they run
in the tycho build, like this:
```
Error: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin
(default-package-plugin) on project org.eclipse.cdt.core.tests:
/home/runner/work/cdt/cdt/core/org.eclipse.cdt.core.tests/build.properties:
bin.includes value(s) [test.xml] do not match any files. -> [Help 1]
```
So make them errors in the workspace so that the issue is
detected before push.
Some build.properties issues don't affect the build, but
are still indicative of a problem.
The long sleep at the end of each thread is to make sure that
while the test code is waiting for an event the "other" thread
doesn't finish. 3 seconds is not long enough for this.
This is similar to why we need dsf.gdb.tests.timeout.multiplier
for other tests. Especially on the build machines the tests
can run much slower causing the sleep to be insufficient.
Increasing this to 30 seconds doesn't make the test suites
take any longer, when they are all passing.
Fixes#119
The parser for dprintf parameters was much too simplistic and
prevents real uses cases from operating.
It is not necessary to remove the , between the arguments to
dprintf, so don't try to split on that anymore. That also
means we can't check for and error on mismatch between format
specifiers and number of arguments.
e.g. "===> XML_EVENT_TEXT(%s)\n", (char *)strtok(Text,"\n")
should be permitted.
The alternative would be to write a more complete parser for
both the printf specification and the arguments. Well out of
scope and unnecessary.
Some inputs may now be accepted by the GUI and then when
inserted with GDB fail. These errors are displayed in the
GUI already anyway.
This fixes numerous warnings like this:
Boolean is a value-based type which is a discouraged argument
for the synchronized statement
and:
Integer is a value-based type which is a discouraged argument
for the synchronized statement
- Fix the running so that the correct gdb is used.
- Only run DSF tests if dsf directories have been modified
- Default to using gdb,gdbserver on the PATH when running
tests
- Remove double reporting of test results
The root files in GitHub are a bit more prominent, so keep
that area clean and move this special ini to a subdir.
Change-Id: I12d95727e9dad29ebe4f50d47faa9e98753a52bc
This mostly is using diamond operator, but includes
adding missing @Override and organizing imports and
applying formatting improvements in the JDT formatter.
Change-Id: Id91cbff33b0a039cc5121945ffbc407ecba45866
The CDT Cleanup profile had a bunch of extra cleanups applied to it, this
prevents running the CDT cleanup profile manually to simulate running the
save actions on all Java files
Change-Id: Iad491e1258a4ba90d81d1457ea0f6779e3663e38
The test used to fail on the -100.0 / 3.0 case if that was the first
condition tested. This change forces that to not be the first
condition tested which reduces the incidence of failures.
This does not resolve the unknown underlying issue which appears
to be on the GDB side that CDT is exposing. Upgrading GDB version
may also resolve the test failures, but for now I am going with
this fix so that we stop having UNSTABLE Jenkins CI builds.
Change-Id: Ibfa93a8350cfc08adf721723bc07566521bed812
While most of these commands don't actually have spaces in them, or
their arguments, avoid the deprecated methods.
Change-Id: If7b4324695699d5a6d9a2f8a979657977486d8a4
Improvements in SyncUtil's addBreakpoint and runToLocation
methods to make them support hardware breakpoint
Change-Id: If358bf11cab426f48edb8854e9ece911c2839815
Signed-off-by: Abdullah Khalid <abdullah.dev0@gmail.com>
Eclipse CDT supports GDB version 6.6 and newer. Some features
in Eclipse CDT require newer versions of GDB. The Eclipse CDT
project focuses its testing time on GDB version 8.0 and newer.
Change-Id: Ifb7cd77c9fae4b9d1b82e0aa8a2cea206a4298b7
this fixes cases where a single test failing does not clean up
properly causing subsequent tests to then fail.
Change-Id: I4bd9c08e5ce1a4cd2ccd5e710a446e6e96c4d353
Instead make the tests non-intermittent. If tests are flaky, they
should be moved to JUnit5 and marked with the flaky tag.
Change-Id: I9c165ec8f16c65383d93d64d17047c0a2597b81c
Many of the disabled tests were failing because they were dependent
on specific combinations of GDB + GCC and where exactly code
stops and steps effect when entering functions. The old code
mostly ran to a function and then stepped a known number of times.
But what changes between GDB versions is how many steps are needed.
Therefore for all failing tests update to run to a specific line
number by using tags in the .cc file and running to them to make
sure the test is precisely on that line.
This partially reverts commit 8220215a2e
and 92272c6465
Reason for revert: These tests were "temporarily" disabled a while ago
as part of the JIRO migration in Bug 545624.
Change-Id: I703429c8a81c856360f1cb4e899026200527f7c6
MIExpressionsTest.testNestedBaseChildrenBug accesses this field like
this -data-evaluate-expression "*((((*(class Base*) this)).pNested))"
which, as pNested isn't init, can cause a Cannot access memory at
address 0x0 error.
Change-Id: Ie6ba01be3499df6e72e714bc5c02dcd5355468bf
