RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java fails after JDK-8327114

Kevin Walls kevinw at openjdk.org
Tue Oct 1 16:58:33 UTC 2024


On Tue, 1 Oct 2024 16:16:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
> 
> 1. Shared volumes between attachee and attacher and shared pid namespace
> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
> 3. Shared pid namespace between attachee and attacher only
> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
> 
> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
> 
> While at it, I've discovered that the `EventGeneratorLoop` running container always runs for a fixed time: `30` seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run `60` seconds. In my test runs using `-summary:time` it was `70` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.08 seconds
>   compile: 2.068 seconds
>   build: 4.842 seconds
>   compile: 4.841 seconds
>   driver: 70.776 seconds
> Test results: passed: 1
> 
> 
> I don't think this is needed. We can destroy the process running `EventGeneratorLoop` and then wait for it to exit rather than sitting there and waiting until it is finished (even though we no longer do anything with it). This improvement has been implemented in https://github.com/openjdk/jdk/commit/5b2f646c73b747f6fff364347031074d24e49822 (separate commit). After this, the total runtime of the test reduces to about `22` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.169 seconds
>   compile: 2.157 seconds
>   build: 4.964 seconds
>   compile: 4.963 seconds
>   driver: 22.928 seconds
> Test results: passed: 1
> 
> 
> The actual test skip of the 4th test case is: https://github.com/openjdk/jdk/commit/95a7cc05f00e94190af583b9f9dbc659c7be879f
> 
> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue?...

Thanks for clarifying the different testing combinations and the pointer to the missing one for follow up in JDK-8341349.
I can check our testing with this change...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2386516815


More information about the serviceability-dev mailing list