Because of
[changes](https://www.eclipse.org/eclipse/news/4.26/platform_isv.php#JobManager_Implementation)
in Eclipse Platform where the jobmanager's behaviour changes (within
the API), the consumers of the jobmanager can deadlock due to incorrect
assumptions.
In particular, where we call job.schedule(), the callback can happen
in different threads to the IJobChangeListener's. As CDT was holding
a lock while calling schedule that is also required in those
listeners, we need to no longer lock when calling schedule.
As the code already dealt with the case of when there was a delay
between the job.schedule() and where & when it was run, we can
move the schedule call out of the synchronized block.
Fixes#81
This change adds the ALL_FLAGS that does not limit tool options to
those declared as IOption::isForScannerDiscovery when launching the
compiler to discover compiler built-ins.
This is needed as many other flags, either entered manually in "Other
flags" or some of the existing flags with checkboxes such as "-ansi",
"-fPIC", and "-fstack-protector-all" which all affect scanner discovery
as they can all change what macros are built-in to the compiler.
The current solution has as a drawback that some settings, like -I and -D
then appear twice. For example in the "Includes" node in the "Project
Explorer"
My only reservation about this change is if there is an option
that can be specified successfully at build time, but when used
at scanner discovery time causes the compiler to fail, or return
incorrect results. Therefore I have added a new field,
excludeFromScannerDiscovery to tool options (buildDefinitions
extension point) that allows tool integrators to always exclude
a command line option from ALL_FLAGS. I have also added
a new "Other flags (excluded from discovery)" to the
"Miscellaneous" tab to allow compiler options to be entered
by the user.
Removed ICBuildConfiguration.getBinaryParserId() and
IToolChain.getBinaryParserId(). Replaced with methods that return a list
of IDs.
Updated API changes doc.
Rearranged tests so that the test for IToolChain is in a new gcc test
plugin.
Update since tags to 8.0.
Remove api filter.
Fix other since tags after removing of api filter.
Remove interface defaults.
Add default implementations where necessary.
Update tests - TBC.
Added ability to return a list of binary parser IDs, rather than a
single ID. This supports build configurations that have multiple
binaries with for example cross toolchains.
Change-Id: I1b7e47bf6a86bbd9f1c6b9646d008bac9479417d
This change solves the indexing of C/C++ files when multiple
toolchains are used in a single Makefile. This is for the use case in
which one (Linux) gcc compiler plus one or more custom embedded C
compilers (all producing ELF format binaries) are used.
To get proper indexing we need to know for each resource which
toolchain was used. The sub build configuration (via extension point
org.eclipse.cdt.core.buildConfigProvider) extends
StandardBuildConfiguration.java, and overrides method IToolChain
(List<String> commandgetToolChain). tcMap is filled with a map of
toolchains per resource. The primary toolchain keeps pointing to the
gcc toolchain.
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.
* Bug 566810: Pull Docker image if necessary
Change-Id: I948e3a273ae598efe563b150922a7bc4b696d05c
Signed-off-by: Moritz 'Morty' Strübe <moritz.struebe@mathema.de>
* docker.launcher: Add tests
* Docker: Fix NPE
This NPE was triggered when the docker image was deleted in the
background.
Change-Id: I7fe8f9204a2f60a5d2396bbc2ec67c7ae820a60a
Signed-off-by: Moritz 'Morty' Strübe <moritz.struebe@mathema.de>
* Bug 566810 Allow setting any Docker image
Allow setting any docker image as string in the input field. There is no
verification yet. If the docker image exists, it is set accordingly.
Change-Id: Iec21798cf79206151067d1e2f3a7ec933f1d0b7d
Signed-off-by: Moritz 'Morty' Strübe <moritz.struebe@mathema.de>
* Bug 566810 Remove volumes immediately
As it is now possible to insert any string, the volumes added by the
image, should be removed immediately, too.
Change-Id: I6c843a2b1e551372e0dff22185d6152faecd72f3
Signed-off-by: Moritz 'Morty' Strübe <moritz.struebe@mathema.de>
This resolve the following exception during the build:
!ENTRY org.eclipse.ui.ide 4 4 2022-11-11 09:45:42.503
!MESSAGE Entry is outside of the target dir: ../
!STACK 0
java.io.IOException: Entry is outside of the target dir: ../
at org.eclipse.ui.wizards.datatransfer.ZipFileStructureProvider.initialize(ZipFileStructureProvider.java:190)
at org.eclipse.ui.wizards.datatransfer.ZipFileStructureProvider.getChildren(ZipFileStructureProvider.java:113)
at org.eclipse.ui.wizards.datatransfer.ImportOperation.importRecursivelyFrom(ImportOperation.java:781)
at org.eclipse.ui.wizards.datatransfer.ImportOperation.execute(ImportOperation.java:385)
at org.eclipse.ui.actions.WorkspaceModifyOperation.lambda$0(WorkspaceModifyOperation.java:110)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
We can fail to regain our lock in other cases than just
operation cancelled exception, so capture all of those
cases to throw an FailedToReAcquireLockException.
Also, fix another finally block that assumes it has the lock.
Fixes#128
These binary parsers have been slated for deleting for
a while and are replaced with 64-bit compatible
versions.
Some methods still refereneced the 32-bit variants
and have been updated to the fully functioning
64-bit variant.
The older parser IDs are preserved (forever?) so that
old projects can be opened without needing to do anything.
The IDs now point at the new implementations.
See also Bug 562495
This extension has been in existence since very early days
of CDT, but it never(?) had a schema, so the improvements
done in #136 will now show errors in use of this extension.
Steps:
======
1. Create a managed project and build it
2. Expand the built binary available in binary container in project explorer view
3. Now clean the project, clean will fail irrespective of number of tries you do
Reason:
=======
For finding the sources for binary, Elf instance is created and Section.mapSectionData creates MappedByteBuffer of channel which locks the file on Windows until its garbage collected, see following
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154
Solution:
=========
Made ISymbolReader AutoCloseable and user is responsible to properly close it. In case of dwarf reader, we remove all the references of ByteBuffer and call gc.
The indexer has a feature that allows readers of the index
to read the index in the middle of write operations. This
is done by using a YeildableIndexLock.
The YeildableIndexLock's yield method can be called to
temporarily give up the write lock. However the assumption
in the code was that it would always successfully
reaquire the lock after that.
However, if the indexing was cancelled the lock would
fail to be reaquired. Therefore the code that thinks it
owns the lock no longer owns it. In this case the code
in PDOMWriter.storeSymbolsInIndex's finally block.
Therefore I have added an new exception type to explicitly
identify this use case so the original code can differentiate
between cases where an exception was thrown where the lock
is still held, and cases where the lock is no longer held.
Note that instead of a new exception caught like this:
```java
} catch (FailedToReAcquireLockException e) {
hasLock = false;
e.reThrow();
```
I could have done this:
```java
} catch (InterruptedException | OperationCanceledException e) {
hasLock = false;
throw e;
```
But it is not obvious that nothing else other than the
acquire can raise an OperationCanceledException because it
is a RuntimeException. By having a new checked exception we
can know for sure that in the finally block we have lost
our lock.
There are no API implications of this change as all the classes
and interfaces are internal to CDT.
Fixes#128
The format of this error message used to look like:
```java
Expected number (0) of Non-OK status objects in log differs from actual (1).
Error while parsing /projC_testTripleDownwardV/h3.h. java.lang.reflect.InvocationTargetException
Caused by: java.lang.reflect.InvocationTargetException
Caused by: java.lang.AssertionError: Need to hold a write lock to clear result caches
```
and it was hard to impossible to identify what the cause is.
The hope is that capturing this fuller stack trace into the log
will make it easier to identify the problem.
Part of #117
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
This helps add some isolation between tests in case background
threads are accessing a project. However I am not sure
this solves any of the actual outstanding flaky tests.
Part of #117
This provides the shared pre/post condition assertions to
help make sure tests are running in a clean environment.
If I had time I would convert all the tests to BaseTestCase5
which is JUnit5, but I only did the tests that had something
wrong with them.
Part of #117
Instead of using assertTrue, but assertEquals we get nice
error messages that show the contents of the collections.
Using assertEquals(List.of() instead of assertArrayEquals(...
because that gives nicer error messages.
Part of #117
The test "abused" the JUnit3 ability to control test order and
required all tests to run in the given order to work.
Refactored the test to remove all redundant try/catch and
provide a more traditional flow.
Part of #117
