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
"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 #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
For Core Build System local debug target. If there is no absolute path
set in the Debugger tab of the launch configuration, try to find the
debugger first in the selected toolchain. If the debugger is not found
in the toolchain, let GdbLaunch search in PATH.
If an absolute path is set, GdbLaunch will use that.
Fixes#1008
Beta versions of maven plugins are omitted from this
upgrade.
A new version of Tycho brings in an update ECJ which means some
of the class files are different, hence the need to bump versions
of bundles too.
A new calendar year brings an update to Copyrights
The CDT Debug Activites was originally added when we had two
distinct debuggers in CDT, the DSF one and the CDI one. To
eliminate confusion the preferences for the respective
debug infrastructures were only displayed if users actually
ran such a debug session.
Now with just one debug infrastructure, we should always display
the preference pages. It also removes some confusion that some
preference pages weren't visible until after you started the
debug session. So for example, users couldn't turn on or off
a bunch of default settings until after creating and launching
a debug session.
I have left the enableActivity call in GdbLaunchDelegate in
case any extenders were hiding some of their UI behind that key.
The only exception in the above is the View Performance preference
page which was misplaced in the top level Run/Debug preference
tree, even though it is CDT specific. That preference page has
been re-parented to C/C++ -> Debug
Fixes https://github.com/eclipse-cdt/cdt/issues/972
Do not check for binaries in the project directory if the user defined
a binary in the Main tab. This supports the case where the user
disables auto build and selects a binary outside the project directory.
Otherwise the binaries check would stop the launch with the message
that no binaries are found in the project.
The launch configuration for local Core Build projects got the
Debugger and Source tabs in debug mode. Now the user can set the stop
at startup, a specific debugger, and all other Debug options as we
know from Managed Build projects.
The GdbLaunch class automatically picks up all the debug settings from
these new tabs. No additional code was needed for that.
The composition of Core Build tab groups is now fully done via the
launchConfigurationTabGroups extension-point.
This change relates to #758. It affects all Core Build projects,
including CMake projects.
A new Main Tab was created for Core Build local projects based on the Main
Tab used for the classic Managed Build projects. It adds these
features:
* Option to select a different binary.
* Option to control launch pre-builds.
The default value for the binary is empty string. With empty string
the behaviour for binary selection stays the same as it was.
The project name is fixed and cannot be changed. A Core Build launch
configuration is created with the project and tied to it.
There is no option to select a build configuration, because for Core
Build projects this is selected via the LaunchBar's Launch Mode.
This change relates to #758. It affects all Core Build projects,
including CMake projects.
- 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)
When launching a GDB debug session using the Launch Bar and a Launch
Target, now the launch takes into account a REMOTE_TCP value in the
launch configuration before considering the type of the Launch Target.
Improves the change submitted in:
Bug 547881 - Allow targets to set ATTR_REMOTE_TCP
Fixes issue #622
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.
target-async is the old name for mi-async. mi-async came
into existence in GDB 7.8, but in later releases it becomes
a warning to use the old name.
Because we already have the version infra for 7.12 we
change to using mi-async from 7.12
A similar change was made for
[cdt-gdb-adapter a while ago](https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/blob/main/src/GDBBackend.ts#L114-L116)
Fixes#176
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
