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
While it may be that the tests don't directly rely
on JUnit5, the IDE requires JUnit5 in the classpath
or else the launch config doesn't work with this error:
Cannot find class 'org.junit.platform.commons.annotation.Testable'
on project build path.
Part of #117
JDT thinks this is a test and will run it in the IDE and display
an error. But it is only used to compose other tests, by making
it abstract the IDE won't see it anymore.
Part of #117
This is an ancient (2004) test that does not apply, was never
referenced in the Suites and whose name doesn't match standard
pattern.
It tried to import ancient versions of projects as well, which
would kick off the project converter UI that can't be disabled
from the core plug-in.
All in all, this test adds nothing of value.
Part of #117
This code seems to be trying to optimize across tests.
This change isolated each individual test better.
Also removed is a bunch of effectively unused test code.
Part of #117
Some of these tests left behind projects, by chaning them
to extend BaseTestCase5 the resource cleanup happens
and the tests are cleaned up properly
Part of #117
Ideally the code itself should also be deleted from CDT, but
this test is super flaky and I cannot seem to convert it to
JUnit5 so I can properly mark it as flaky. Therefore
the test is now simply gone.
Part of #117
The resource helper is widely used, but when it deletes
projects, it leaves their contents on disk. Fix this
so that the contents on disk is deleted.
Part of #117
Maybe once upon a time this lifecycle did something,
but now in setUp fProject is always null and therefore
the project was never getting deleted as the fProject
that deleteProject saw was different than
the tests.
Part of #117
