Gradle构建卡在“等待获取守护进程地址注册表共享锁”上。

Question

Gradle构建卡在“等待获取守护进程地址注册表共享锁”上。

29

我目前正在使用HP Fortify工具对一个项目进行安全漏洞扫描。在扫描时，Fortify的CLI允许构建工具将其集成到CLI命令中，以便构建并同时扫描项目中存在的文件。我正在使用以下命令：

sourceanalyzer -b mcapbookvalue -gradle -verbose ./gradlew -x test --console=verbose -debug --continue assemble

但是生成过程停滞在:

2020-01-14T12:31:39.836-0500 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.[0K
2020-01-14T12:31:39.836-0500 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2020-01-14T12:31:39.836-0500 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2020-01-14T12:31:39.836-0500 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2020-01-14T12:31:39.836-0500 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.

如果我只是使用以下命令而不是Fortify的集成命令来构建项目，则构建成功：

./gradlew -x test --console=verbose -debug --continue assemble

我无法弄清楚为什么Gradle构建会卡住。读取和理解线程转储日志中发生的情况对我来说太难了。

线程转储（jstack日志）：https://drive.google.com/file/d/13b6vdDGCWoke7McM_FJROVOkvTaRGqem/view?usp=sharing

如果收到任何帮助，将非常感激。

提前致谢。

- Sekhar Routray

我发现的另一个小细节是，与Fortify集成的Gradle构建在Windows机器上可以成功运行，但在Linux机器上却不行。 - Sekhar Routray

使用 nebula.rpm 插件时出现了相同的问题。 - Jonathan Komar

1

你是否偶然在nfs上有GRADLE_HOME目录？ - Federico Nafria

我不明白你所说的nfs是什么意思。但是我已经将GRADLE_HOME添加到Win 10和我的Linux系统的路径变量中了。 - Sekhar Routray

你的 Linux 机器的内存和 CPU 配置比 Windows 机器低的可能性大吗？如果有争用，你可以在 Linux 机器上检查 CPU 使用率和内存使用率。 - swapyonubuntu

简化您的运行过程，禁用Gradle守护进程和缓存。使用--no-daemon和--no-build-cache选项有什么区别吗？ - undefined

2个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- chubbsondubs · Answer 1

所以线程转储实际上是开发人员查看的工具。用户（甚至像你和我这样的其他软件开发人员）如果不了解代码库，就无法真正从中调试问题。很好，你包含了它，这样如果有更有经验的人来了，他们可以给我们一些见解。

话虽如此，如果你之前在自己的项目中使用过线程转储，你就可以开始看出可能发生的情况。再次声明，我不是一个Gradle开发人员，所以这只是个人见解。但基本上，我们只对状态为“WAITING（在对象监视器上）”的线程感兴趣。而这样的线程只有4个。Finalizer、Common Cleaner、Daemon #20和一个执行工作者。Finalizer和Common Cleaner都没有做任何工作，所以可以忽略它们。Daemon #20似乎是一个启动Gradle脚本的Gradle守护线程，所以它只是在等待脚本完成，这是预期的。所以剩下的就是执行工作者，它看起来像这样：

"Execution worker for ':'" #42 prio=5 os_prio=0 cpu=2818.31ms elapsed=196.05s tid=0x00007f9358702800 nid=0x16cfe in Object.wait()  [0x00007f93428f1000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(java.base@11.0.5/Native Method)
    - waiting on <0x00000000ea1d41f8> (a java.lang.ProcessImpl)
    at java.lang.Object.wait(java.base@11.0.5/Object.java:328)
    at java.lang.ProcessImpl.waitFor(java.base@11.0.5/ProcessImpl.java:495)
    - waiting to re-lock in wait() <0x00000000ea1d41f8> (a java.lang.ProcessImpl)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.5/Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.5/NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.5/DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(java.base@11.0.5/Method.java:566)

有趣的部分是java.lang.ProcessImpl.waitFor，所以似乎gradle只是在等待外部进程完成。这似乎不是死锁情况或任何奇特的锁定问题，这是好消息。基本上，HP工具只是在运行而没有完成。突然间，“停机问题”变得太真实了。它会完成还是挂起了？我们无法知道。

但是我会查看Linux上的top输出，并找到gradle启动的进程（即HP进程）。该进程的CPU使用率是否在波动？那么可能只是在执行一些耗时的操作，耐心等待，让它运行，并查看是否完成。如果它没有运行，那么你就有一个更大的问题。我敢打赌，在Linux上，HPI软件可能正在尝试扫描一些不应该扫描的东西，也许这是一个配置问题或Linux与Windows之间的差异。这完全是猜测，只是我的直觉。

我的下一步可能是看看我是否可以在gradle之外的Linux上手动运行该工具。从转储中我们发现，gradle似乎并没有导致这个问题，所以让我们将HP工具隔离出来，看看是否可以获得更多的错误信息或其他相关内容。以下是一些需要考虑的事项：

- gradle是否为其提供足够的内存来运行？如果您手动运行的可执行文件与Gradle的不同，可能是Linux与Windows之间的配置差异。 - 是否涉及HP工具的gradle插件，并且在Linux上是否需要配置某些选项？ - Linux服务器上是否有足够的可用内存来同时运行HP工具和gradle？也许您的Linux服务器的内存上限与Windows服务器不同。如果您可以启动一个更大的服务器，也许这个问题就可以解决。

今天我没有完整的答案给您，只是给您一个解决这个问题的策略。祝您好运。

- Arijit · Answer 2

你遇到的问题似乎与Gradle守护进程及其对守护进程地址注册表的锁有关。Gradle守护进程是运行Gradle构建的后台进程，它使用锁来管理对某些资源的访问。

以下是您可以尝试的几个可能的解决方案：

停止并重新启动Gradle守护进程：在您的项目目录中，运行以下命令以停止Gradle守护进程：

./gradlew --stop

然后，尝试再次运行您的构建命令，看看是否解决了问题。

禁用Gradle守护进程：您可以通过将--no-daemon选项添加到构建命令中来禁用Gradle守护进程。例如：

./gradlew --no-daemon -x test --console=verbose -debug --continue assemble

禁用守护进程可能会稍微减慢构建启动时间，但如果守护进程本身存在问题，则可以帮助解决问题。

升级Gradle：确保您正在使用最新版本的Gradle。您可以在Gradle网站上检查最新版本，或在项目目录中运行./gradlew --version来检查。如果您正在使用旧版本，请考虑升级以查看是否解决了问题。
检查冲突进程：可能有另一个正在运行的Gradle构建或进程，它正在保持守护程序地址注册表上的锁定。在启动构建之前，请检查是否有任何其他正在运行的Gradle进程并终止它们。
分析线程转储：如果问题仍然存在，并且您想进一步调查问题，您可以分析线程转储日志以识别任何潜在的瓶颈或冲突。您可以与Gradle社区或Fortify支持共享线程转储日志，以获得帮助理解问题。

值得一提的是，问题可能特定于Fortify和Gradle之间的集成。在这种情况下，联系Fortify支持或检查他们的文档或社区论坛以获取与Gradle集成相关的已知问题和解决方案可能会有所帮助。

我希望这些建议能帮助您解决问题并成功地将Fortify集成到您的Gradle构建中。