Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

PluginBuildPluginTests fails on Mac #47417

Closed
mark-vieira opened this issue Oct 1, 2019 · 5 comments · Fixed by #47713
Closed

PluginBuildPluginTests fails on Mac #47417

mark-vieira opened this issue Oct 1, 2019 · 5 comments · Fixed by #47713
Labels
:Delivery/Build Build or test infrastructure Team:Delivery Meta label for Delivery team >test-failure Triaged test failures from CI

Comments

@mark-vieira
Copy link
Contributor

This test was failing for me locally and not in CI, but turns out it's failing in our Darwin CI builds as well:

https://gradle-enterprise.elastic.co/s/t3qxgarzcyfls

Something about the randomized runner thread leak detection is tripping only on OSX. We might want to reevaluate whether we want to use any of the randomized runner stuff in buildSrc tests at all. We aren't actually using any of the random input capabilities, and I suspect this is just copy/paste from the regular ES code.
@mark-vieira mark-vieira added :Delivery/Build Build or test infrastructure >test-failure Triaged test failures from CI labels Oct 1, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (:Core/Infra/Build)

@mark-vieira
Copy link
Contributor Author

pinging @atorok

@alpar-t
Copy link
Contributor

alpar-t commented Oct 4, 2019 

3 threads leaked from TEST scope at testApply(org.elasticsearch.gradle.plugin.PluginBuildPluginTests): 
   1) Thread[id=26, name=Exec process Thread 3, state=TIMED_WAITING, group=TGRP-PluginBuildPluginTests]
        at java.base@12.0.2/jdk.internal.misc.Unsafe.park(Native Method)
        at java.base@12.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at app//org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.base@12.0.2/java.lang.Thread.run(Thread.java:835)
   2) Thread[id=25, name=Exec process Thread 2, state=TIMED_WAITING, group=TGRP-PluginBuildPluginTests]
        at java.base@12.0.2/jdk.internal.misc.Unsafe.park(Native Method)
        at java.base@12.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at app//org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.base@12.0.2/java.lang.Thread.run(Thread.java:835)
   3) Thread[id=22, name=Exec process, state=TIMED_WAITING, group=TGRP-PluginBuildPluginTests]
        at java.base@12.0.2/jdk.internal.misc.Unsafe.park(Native Method)
        at java.base@12.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
        at java.base@12.0.2/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
        at java.base@12.0.2/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at app//org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.base@12.0.2/java.lang.Thread.run(Thread.java:835)

I don't think we are creating Mac specific threads, so these must be leaked by Gradle.
I'm going to turn off the check for this test.

The randomized runner has a few other features than generating predictable pseudo random test inputs, we run with this runner for consistency with other projects.

alpar-t added a commit to alpar-t/elasticsearch that referenced this issue Oct 4, 2019
@alpar-t
Fix PluginBuildPluginTests on mac
6afc8d8 
We skip the thread leak check because it seems Gradle is leaking them
and there's nothing we can do.

Closes elastic#47417.
@mark-vieira
Copy link
Contributor Author

Looks good. Do you intend on opening a PR for that?

@alpar-t alpar-t mentioned this issue Oct 5, 2019
Closed
@alpar-t
Copy link
Contributor

alpar-t commented Oct 5, 2019

Yes, sorry I taught I did :)

rjernst added a commit to rjernst/elasticsearch that referenced this issue Oct 7, 2019
@rjernst
Filter out special gradle threads from leak control
d13c109 
This commit adds a thread filter for gradle unit tests which omits
threads gradle may create that we have no control over shutting down.
The current example of this is for project.exec which gradle pools.

closes elastic#47417
@rjernst rjernst mentioned this issue Oct 7, 2019
Merged
rjernst added a commit that referenced this issue Oct 8, 2019
@rjernst
Filter out special gradle threads from leak control (#47713)
603c3e6 
This commit adds a thread filter for gradle unit tests which omits
threads gradle may create that we have no control over shutting down.
The current example of this is for project.exec which gradle pools.

closes #47417
rjernst added a commit that referenced this issue Oct 9, 2019
@rjernst
Filter out special gradle threads from leak control (#47713)
54c2aec 
This commit adds a thread filter for gradle unit tests which omits
threads gradle may create that we have no control over shutting down.
The current example of this is for project.exec which gradle pools.

closes #47417
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
:Delivery/Build Build or test infrastructure Team:Delivery Meta label for Delivery team >test-failure Triaged test failures from CI
Projects
None yet
Milestone
No milestone
3 participants
@alpar-t @mark-vieira @elasticmachine