Java Application Hang on Linux at "java.io.UnixFileSystem.getBooleanAttributes0"

Question

Our customers application seems to hang with the following stack trace:

  java.lang.Thread.State: RUNNABLE
    at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
    at java.io.UnixFileSystem.getBooleanAttributes(Unknown Source)
    at java.io.File.isFile(Unknown Source)
    at org.tmatesoft.svn.core.internal.wc.SVNFileType.getType(SVNFileType.java:118)
    at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createUniqueFile(SVNFileUtil.java:299)
    - locked <0x92ebb2a0> (a java.lang.Class for org.tmatesoft.svn.core.internal.wc.SVNFileUtil)
    at org.tmatesoft.svn.core.internal.wc.SVNRemoteDiffEditor.createTempFile(SVNRemoteDiffEditor.java:415)
    at org.tmatesoft.svn.core.internal.wc.SVNRemoteDiffEditor.applyTextDelta(SVNRemoteDiffEditor.java:255)

Anyone know what could cause it to hang in isFile?

Answer 1

No idea, but the obvious question of which JDK/JRE comes to mind and what others have you tried...

Answer 2

Perhaps the SVN repository is somehow locked All I can do is guess.

Does the application access a subversion repository?

It might be waiting for the repository to be not locked again, who knows its your application.

Answer 3

getBooleanAttributes0 calls stat (or stat64, if available). If you have the OpenJDK source code, this is listed in file jdk/src/solaris/native/java/io/UnixFileSystem_md.c.

So the real question is, why is stat frozen? Is the file being accessed a network file on a server that's down, for example? If this is a reproducible problem, you may wish to use strace to attach to the Java process, just prior to the freezing. Then look in the output for calls to stat, to see what's being accessed.

Answer 4

Looks like the stat call that results from getBooleanAttributes0 is blocking. This typically happens because the file is located on an NFS share which is down.

Answer 5

We see this issue in Eclipse when it stats a non-existent file in a NFS automount directory.

If you strace your java process with -f -t -T (follow forks and time) what we see is that most the stats return in a very short time. The ones in the automount directory take two orders of magnitudes longer.

In many cases the OS takes this as an opportunity to context switch the thread out. The result is that the thread performing the stat is not running for a very long time. If your Java code (an Eclipse plugin in our case) is inefficiently stating up the tree recursively for every file, you can end up locking up that thread for a long time.

The solution, is to stop your Java from doing that.