Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Wed Jan 3 16:57:28 UTC 2018

Sorry, I should've mentioned that this is 8u152.

On Wed, Jan 3, 2018 at 11:56 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

Hi all,

Consider the following stacktraces of the main app thread and a background thread: "main" #1 prio=5 osprio=0 tid=0x0000000001bfd000 nid=0x1958 waiting for monitor entry [0x00002b98ceba3000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.Runtime.loadLibrary0(Runtime.java:862) - waiting to lock <0x00000007bf834b20> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:1122) at sun.nio.fs.UnixNativeDispatche r$1.run(UnixNativeDispatcher.java:573) at sun.nio.fs.UnixNativeDispatche r$1.run(UnixNativeDispatcher.java:571) at java.security.AccessController.doPrivileged(Native Method) at sun.nio.fs.UnixNativeDispatche r.(UnixNativeDispatcher.java:571) at sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:67) at sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) at sun.nio.fs.LinuxFileSystemProv ider.newFileSystem(LinuxFileSystemProvider.java:46) at sun.nio.fs.LinuxFileSystemProv ider.newFileSystem(LinuxFileSystemProvider.java:39) at sun.nio.fs.UnixFileSystemProvi der.(UnixFileSystemProvider.java:56) at sun.nio.fs.LinuxFileSystemProvider.( LinuxFileSystemProvider.java:41) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorA ccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstruc torAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor. newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at sun.nio.fs.DefaultFileSystemPr ovider.createProvider(DefaultFileSystemProvider.java:48) at sun.nio.fs.DefaultFileSystemPr ovider.create(DefaultFileSystemProvider.java:63) at java.nio.file.FileSystems$Defa ultFileSystemHolder.getDefaultProvider(FileSystems.java:108) at java.nio.file.FileSystems$Defa ultFileSystemHolder.access$000(FileSystems.java:89) at java.nio.file.FileSystems$Defa ultFileSystemHolder$1.run(FileSystems.java:98) at java.nio.file.FileSystems$Defa ultFileSystemHolder$1.run(FileSystems.java:96) at java.security.AccessController.doPrivileged(Native Method) at java.nio.file.FileSystems$Defa ultFileSystemHolder.defaultFileSystem(FileSystems.java:96) at java.nio.file.FileSystems$Defa ultFileSystemHolder.(FileSystems.java:90) at java.nio.file.FileSystems.getD efault(FileSystems.java:176) at java.nio.file.Paths.get(Paths.java:84) at .ServiceLoader.s etup(ServiceLoader.java:446) at .MetadataAdminLo ader.main(MetadataAdminLoader.java:52)

"shardDbExecutor-0-pool-0" #33 prio=5 osprio=0 tid=0x0000000001ebf000 nid=0x1d01 in Object.wait() [0x00002b991f941000] java.lang.Thread.State: RUNNABLE at java.nio.file.FileSystems.getD efault(FileSystems.java:176) at java.nio.file.Paths.get(Paths.java:138) at sun.misc.Launcher$ExtClassLoad er.findLibrary(Launcher.java:224) at java.lang.ClassLoader.loadLibr ary(ClassLoader.java:1830) at java.lang.Runtime.loadLibrary0(Runtime.java:870) - locked <0x00000007bf834b20> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:1122) at sun.security.ec.SunEC$1.run(SunEC.java:60) at sun.security.ec.SunEC$1.run(SunEC.java:58) at java.security.AccessController.doPrivileged(Native Method) at sun.security.ec.SunEC.(SunEC.java:58) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorA ccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstruc torAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor. newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at sun.security.jca.ProviderConfi g$2.run(ProviderConfig.java:221) at sun.security.jca.ProviderConfi g$2.run(ProviderConfig.java:206) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfi g.doLoadProvider(ProviderConfig.java:206) at sun.security.jca.ProviderConfi g.getProvider(ProviderConfig.java:187) - locked <0x00000007bea03f48> (a sun.security.jca.ProviderConfig) at sun.security.jca.ProviderList. getProvider(ProviderList.java:233) at sun.security.jca.ProviderList. getService(ProviderList.java:331) at sun.security.jca.GetInstance.g etInstance(GetInstance.java:157) at javax.net.ssl.SSLContext.getIn stance(SSLContext.java:156) at com.microsoft.sqlserver.jdbc.T DSChannel.enableSSL(IOBuffer.java:1658) at com.microsoft.sqlserver.jdbc.S QLServerConnection.connectHelper(SQLServerConnection.java:1976) at com.microsoft.sqlserver.jdbc.S QLServerConnection.login(SQLServerConnection.java:1627) at com.microsoft.sqlserver.jdbc.S QLServerConnection.connectInternal(SQLServerConnection.java:1458) at com.microsoft.sqlserver.jdbc.S QLServerConnection.connect(SQLServerConnection.java:772) at com.microsoft.sqlserver.jdbc.S QLServerDriver.connect(SQLServerDriver.java:1168) at java.sql.DriverManager.getConn ection(DriverManager.java:664) at java.sql.DriverManager.getConn ection(DriverManager.java:208) at .ConnectionPool. createGoodConnection(ConnectionPool.java:565) at .ConnectionPool. createNewConnection(ConnectionPool.java:519) at .ConnectionPool. getConnection(ConnectionPool.java:407) at .StatementCachingConnectionImpl. setupConnection(StatementCachingConnectionImpl.java:94) at .StatementCachin gConnectionImpl.(StatementCachingConnectionImpl.java:54) at .TestConnectionF actories$FaultInjectingConnection.(TestConnectionFactories.java:90) at .TestConnectionF actories.lambda$static$3(TestConnectionFactories.java:33) at .TestConnectionFactories$$Lambda$12/ 1738236591.newConnection(Unknown Source) at .SedaExecutor.se tupConnections(SedaExecutor.java:130) at .SedaExecutor$Se daThreadFactory.lambda$newThread$0(SedaExecutor.java:165) at .SedaExecutor$Se daThreadFactory$$Lambda$22/1392419022.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) The application intermittently hangs on startup, and the above callstacks are present. It seems like there's a deadlock due to concurrent class loading and default FileSystem initialization (which itself triggers class loading here). I wasn't able to find any existing JBS entries reporting anything similar. Am I seeing this right? Is this a known issue? Thanks

More information about the core-libs-dev mailing list