`dokkaHtml` is simply hanging... I see that a dead...

# dokka

[rocketraman]

dokkaHtml is simply hanging... I see that a deadlock was recently fixed for multiplatform projects but I'm already on 1.7.10

[rocketraman]

I'm on Linux and the project does have an ios target. dokkaHtml seems to work on a Mac without hanging.

[Vadim Mishenev]

Can you provide us your project and log?

[rocketraman]

The master branch of this project: https://github.com/innertech/hawkish-bewit

[Vadim Mishenev]

I have executed ./gradlew dokkaHtml on Linux. It works.
Can you elaborate on how I can reproduce hanging?

[rocketraman]

Good question. I don't know what's different about my env. What should I dig into? Want to see a stack trace?

[rocketraman]

In debug mode, right after "Creating documentation models", the process just appears to be doing this over and over:

2022-08-24T20:14:43.292-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2022-08-24T20:14:43.292-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2022-08-24T20:14:43.293-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.

[rocketraman]

A stack dump on the daemon shows some dispatcher threads that appear to be hung while unzipping kotlin metadata:

"DefaultDispatcher-worker-12" #1288 daemon prio=5 os_prio=0 cpu=50.47ms elapsed=156.96s tid=0x00007fc47c0155a0 nid=0x3f962d runnable  [0x00007fc201dfb000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.fs.UnixNativeDispatcher.getpwuid(java.base@17.0.3/Native Method)
        at sun.nio.fs.UnixUserPrincipals.fromUid(java.base@17.0.3/UnixUserPrincipals.java:114)
        at sun.nio.fs.UnixFileAttributes.owner(java.base@17.0.3/UnixFileAttributes.java:200)
        - locked <0x000000077f13cb28> (a sun.nio.fs.UnixFileAttributes)
        at sun.nio.fs.FileOwnerAttributeViewImpl.getOwner(java.base@17.0.3/FileOwnerAttributeViewImpl.java:89)
        at java.nio.file.Files.getOwner(java.base@17.0.3/Files.java:2202)
        at jdk.nio.zipfs.ZipFileSystem.lambda$initOwner$2(jdk.zipfs@17.0.3/ZipFileSystem.java:252)
        at jdk.nio.zipfs.ZipFileSystem$$Lambda$515/0x00000008010a2120.run(jdk.zipfs@17.0.3/Unknown Source)
        at java.security.AccessController.executePrivileged(java.base@17.0.3/AccessController.java:807)
        at java.security.AccessController.doPrivileged(java.base@17.0.3/AccessController.java:569)
        at jdk.nio.zipfs.ZipFileSystem.initOwner(jdk.zipfs@17.0.3/ZipFileSystem.java:253)
        at jdk.nio.zipfs.ZipFileSystem.<init>(jdk.zipfs@17.0.3/ZipFileSystem.java:154)
        at jdk.nio.zipfs.ZipFileSystemProvider.getZipFileSystem(jdk.zipfs@17.0.3/ZipFileSystemProvider.java:125)
        at jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(jdk.zipfs@17.0.3/ZipFileSystemProvider.java:120)
        at org.jetbrains.kotlin.konan.file.ZipUtilKt.zipFileSystem(ZipUtil.kt:25)
        at org.jetbrains.kotlin.konan.file.ZipUtilKt.withZipFileSystem(ZipUtil.kt:59)
        at org.jetbrains.kotlin.konan.file.ZipUtilKt.withZipFileSystem(ZipUtil.kt:62)
        at org.jetbrains.kotlin.library.impl.BaseLibraryAccess.inPlace(KotlinLibraryLayoutImpl.kt:67)
        at org.jetbrains.kotlin.library.impl.MetadataLibraryImpl.packageMetadataParts(KotlinLibraryImpl.kt:72)
        at org.jetbrains.kotlin.library.impl.KotlinLibraryImpl.packageMetadataParts(KotlinLibraryImpl.kt)
        at org.jetbrains.kotlin.backend.common.serialization.metadata.impl.KlibMetadataDeserializedPackageFragmentsFactoryImpl.createDeserializedPackageFragments(KlibMetadataDeserializedPackageFragmentsFactoryImpl.kt:33)
        at org.jetbrains.kotlin.serialization.konan.impl.KlibMetadataModuleDescriptorFactoryImpl.createPackageFragmentProvider(KlibMetadataModuleDescriptorFactoryImpl.kt:115)
        at org.jetbrains.kotlin.idea.klib.UtilsKt.createKlibPackageFragmentProvider(utils.kt:122)
        at org.jetbrains.dokka.analysis.resolve.DokkaNativeResolverForModuleFactory.createResolverForModule(DokkaNativeResolverForModuleFactory.kt:61)

[rocketraman]

Interestingly I have some IDE freezes as well recently and I think I've seen the same stack there too... https://youtrack.jetbrains.com/issue/KT-53713/IDE-completely-hung-requires-kill-9-to-close-JVM-is-still-responding-jstack-works-etc

[rocketraman]

I think I've figured it out, it appeared to have been some kind of problem with the nsswitch.conf / pam configuration on my system (probably related to my yubikey) ... resetting things with authselect select --force minimal seems to have fixed the problem.