SS causes segfault and crashes JVM
jeffreykog opened this issue · comments
When running forgegradle's build task, FG tries to reobfuscate the produced jars using SS. Somehow, this crashes the JVM.
Gradle log (not much information): http://pastebin.com/enktViLV
JVM error report: http://pastebin.com/iWNdMrAQ
This is not an FG issue, as the lines in the JVM error report clearly point to specialsource.
I believe this is related: MinecraftForge/ForgeGradle#64
It may be, but i am not running this in jenkins, so the conclusion in that issue that it's jenkins' fault is not true. It is about something modifying the jar while loading it, but while reobfuscation, SS is the only thing touching it
Yeah I should rename that issue. We figured out that it's reproducible on any linux distro without jenkins.
Seems to be only an issue when there are multiple processes obfusicating things at the same time, and thus the jar gets overwritten. We fixed this by using a temporary randomly named file for each run.
However, I would suggest that the Jar class gets a close method to clean up those leaky JarFile's
Why is obfuscation being done in parallel?
Closing the jar file might fix the hs_pid hard crash, however it certainly wont fix the MALFORMED one, as that is the result of the file being modified by multiple things at the same time.
Not sure why it's being run in parallel, i'd assume multiple jobs running on jenkins?
As I said, we solved that issue on our end by making it a random temp file, but having a closure would still be nice.
Also, Making Jar's constructor atleast protected ;)
This is not only a problem on jenkins, also the random temp file thing still does not work when you have a lot of subprojects. On irc abrar found out that when you have more than 3 it won't work. Maybe the reobfuscation of subprojects is ran in parallel and it hits some kind of thread limit?
Not sure why it's being run in parallel, i'd assume multiple jobs running on jenkins?
As I said, we solved that issue on our end by making it a random temp file, but having a closure would still be nice.
Also, Making Jar's constructor atleast protected ;)—
Reply to this email directly or view it on GitHub.
Interesting, throw a resource logger on your computer and see what reads/writes to the jars being obfsuicated?
Of, if SS wants, it can try reading all of the data from the file into memory once on load, and then immediatly closing the resource, so that it doesnt have a chance to be swapped out...
was an FG issue. been fixed.