With a gradle multiproject, SS may be illegally altering a zip and crashing on Linux

[mezz]

I have a gradle multproject, Binnie's mods. A Linux build server is set up to automatically build the combined mod jar. The build crashes at "reobf" every time, and the gradle daemon quits with no error message. Travis log.

This turned out to be caused by a JDK crash which I reported and hope to hear back on.

@cpw was able to reproduce the issue on his Linux machine, and believes the JDK crash is caused by some part of the build process reading a zip file while another is editing it. This only crashes on Linux because Windows locks the file and Linux does not.

We suspect SpecialSource is involved, if not I still hope to get your thoughts on this.

[matthewprenger]

Interesting that this popped up again. Sounds like the exact same problem I had years ago.

MinecraftForge/ForgeGradle#64 and MinecraftForge/ForgeGradle@71b0177266c865e604d3419e386f54b74ebec5bc

[mezz]

Thanks, it really does look the same. The code has been refactored since then, maybe the bug is back?

[AbrarSyed]

The internals of the reobfuscation task shouldn't have changed. As far as I know (well, since I'm out of the loop I could be wrong) the reobfuscation process has not significantly changed.

On August 27, 2017 1:04:25 AM CDT, mezz notifications@github.com wrote:

Thanks, it really does look the same. The code has been refactored since then, maybe it the bug is back?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/md-5/SpecialSource/issues/45#issuecomment-325179129

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[mezz]

Here is the current code, it looks similar to the original fix but not really identical. https://github.com/MinecraftForge/ForgeGradle/blob/FG_2.3/src/main/java/net/minecraftforge/gradle/user/TaskSingleReobf.java#L174

[mezz]

I have a hard time seeing if the current code has an issue, it looks fine to me.

[mezz]

Further investigation from Player, Tahg, and cpw show that Java 9 has fixed this long-standing JDK issue. There are some issues building the project with Java 9 but I think they may be easier than solving this one.

[md-5]

Java crashes are generally Java bugs. Unless something SS is doing is always triggering this Java bug, I don't think its really our issue

[LunNova]

Maybe this would be fixed by using JarFile.close() (recently added) where appropriate in ForgeGradle?

That PR was made because FG currently leaks file handles. However SpecialSource hasn't yet had a new release since that PR was merged so I hadn't made a PR for ForgeGradle to use JarFile.close.

A crash under ZipFile.getEntry can be reproduced by doing a build in a gradle daemon, forcibly closing the zip file handles (eg with process explorer on windows), then doing another build in the same daemon.

Even though the ZipFile being accessed after the crash is a new instance of ZipFile, the native implementation of ZipFile caches file handles: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/9d617cfd6717/src/share/native/java/util/zip/ZipFile.c#l99

[mezz]

That sounds plausible. I'm pretty sure this is an FG issue and not SS directly. @md-5 could you make a new SS release so we can implement this FG fix and see if it has an effect?

[md-5]

I've release SS-1.8 and it will be in central soon. Note however that it also includes Java 9 support so that will almost certainly have other effects on FG.