pthread_mutex_lock+0x4 error that causes CTD
Vetpetmon opened this issue · 22 comments
LATEST OBSERVATION: #89 (comment)
Multithreading during loading error
latest.log
Right at the end of this log, is a fatal JRE error:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f9af2e97f74, pid=906808, tid=0x00007f9af2dff640
#
# JRE version: Java(TM) SE Runtime Environment (8.0_381) (build 1.8.0_381-b09)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.381-b09 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libc.so.6+0x97f74] pthread_mutex_lock+0x4
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /mnt/wwn-0x50014ee0aec8bffb-part2/multiMC/instances/CBT- New Horizons/minecraft/hs_err_pid906808.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
JRE: 8u381 on Linux, 64-bit.
OS: Linux, Pop!_OS 22.04
Affected versions: Groovyscript 0.6.0 to 0.6.4
Did some research on this: Pthread API is multithreading. I am currently taking apart the JDK to find any code related to threading, along with Groovyscript.
Pthreads documentation: https://docs.oracle.com/cd/E18752_01/html/816-5137/tlib-1.html
Other issues involving Java & pthreads, but with different frames: xerial/sqlite-jdbc#509 and plan-player-analytics/Plan#1814
Important quotes:
It's an issue of a prepared statement being finalized while it's in use. There are flows in prepared statements that are not synchronized with the close() flow.
Looks like the page was accessed before the cache system was fully functional
Hypothesis: Groovyscript is attempting multithreading during loading the game, in order to speed up the loading process. However, this multithreading may not be thread-safe, and therefore, should not be performed or should have further checks before attempting to thread. A possible solution according to this hypothesis would be to make the multithreading during loading optional in a configuration file, which is referenced before it starts running scripts.
Interesting note: Groovy is trying to close the JRE:
[13:52:26] [Client thread/WARN] [FML]: =============================================================
[13:52:26] [Client thread/WARN] [FML]: MOD HAS DIRECT REFERENCE System.exit() THIS IS NOT ALLOWED REROUTING TO FML!
[13:52:26] [Client thread/WARN] [FML]: Offender: groovy/ui/GroovyMain.processArgs([Ljava/lang/String;Ljava/io/PrintStream;Ljava/io/PrintStream;)V
[13:52:26] [Client thread/WARN] [FML]: Use FMLCommonHandler.exitJava instead
[13:52:26] [Client thread/WARN] [FML]: =============================================================
I think it may be the multithreading that is messing with loading, as seen with this error happening in concerningly large amounts:
[13:52:38] [Client thread/WARN] [FML]: Potentially Dangerous alternative prefix `cbt` for name `hv_circuit_4bit_operator_design_1`, expected `groovyscript`. This could be a intended override, but in most cases indicates a broken mod.
(varies based on resourcename, but 'cbt' and 'groovyscript' remain constant)
java.lang.IllegalArgumentException: The registry name of the item must be non-null and not match an already registered item!
Then after this: [13:52:41] [Client thread/INFO] [groovyscript]: Running Groovy scripts during preInit took 5036 ms
Followed by: [Client thread/INFO] [FML]: Configured a dormant chunk cache size of 0
Ends at: [Forge Version Check/INFO] [forge.VersionCheck]: Global Forge version check system disabled, no further processing.
I had Forge set to do the version check before this log, but because it ends there, I tried disabling the version check to see if that was the case. However, nothing changed except for that line.
The pthread (multithreading) error happens right after Groovyscript finishes creating the script sandbox, which happens before the dormant chunk cache is being configured. Someone who has a windows PC, please send over a log as a control variable that I can compare with.
@Vetpetmon try to test with an older version of groovyscript aka 0.5.x to see if the ctd issue is still there.
ill provide the script since this person was playtesting my pack for reference
Confirmed that this happens with other modded setups, even without GS scripts, all on the same OS.
not clear if this core thread dump can be reproduced in openjdk as well
Reproduced in java 8 openjdk amd64. It's both Oracle and OpenJDK, and this only dumps when Groovyscript 0.6+ is added to the modlist.
must be a problem related to the same OS, try another OS
No idea if this is from Groovyscript side or Pop OS side
To be clear, an identical issue was reported here to also Ubuntu (Pop OS is based on it) 22.04. I'd try resurrect this github issue in the mean time while I try to debug this.
The only workaround i could think of right now is to not use some linux distros and use another operating system
not clear if this core thread dump can be reproduced in openjdk as well
i would believe this crash is only possible if groovyscript was using an external library that did not work on linux for some reason
latest.log
No other mods than GS and the MixinBooter (as the latter is required by the former)
Ran a setup without any scripts using GT:CEU in addition:
latest.log
Neither crash upon loading.
It seems as the script loading is causing the crashing. Attempting to get a full core dump from the other modpack (which has scripts) that has been giving me issues right now.
Update:
-XX:+CreateMinidumpOnCrash does not generate a file and -XX:+CreateCoredumpOnCrash does not exist for the JRE. What version of Java are you using?
Found the full error log for the frame regardless:
Will edit this when I find some possible root causes
EDIT: Whuh oh, something didn't play nicely with Xorg (X11), specifically the Swing library. The Swing library has caused me issues before with my own mod, but oddly enough, only in a dev environment. It happens shortly before trying to open a new window.
Tried with Eclipse Temurin, still got the error.
hs_err_pid995795.log
Rebooting, updating drivers, etc. did not resolve the issue.
@Vetpetmon try to test with an older version of groovyscript aka 0.5.x to see if the ctd issue is still there.
Your modpack's GT:CEU will only accept versions 0.6.0 or higher, but other packs with 0.5.x or lower do not have the same issue. I've had TerraFirmaGreg run with no issues before when Groovyscript was below 0.6.x
Versions I've ran before successfully:
- 0.4.6 (In Terrafirmagreg: New Horizons)
Successfully means that they ran without creating this specific type of error.
This seems to be a bug that I cba to do something as it is very oddly specific and requires very odd setups to occur,
Although backwards groovyscript compatibility should be maintained whenever possible in GTCEu, as to avoid breaking things. For reference my modpack is using the latest GregTech CEu version
I want you to conduct this simple test
Run pure forge instance with on GS installed and see if it crash same
Or only when you are running modpack
If it is crash, then try add this to the jvm argument: -XX:+CreateCoredumpOnCrash
Then upload it via cloud storage and provide link to it here
Since you have indicated that
Confirmed that this happens with other modded setups, even without GS scripts, all on the same OS.
Update:
-XX:+CreateMinidumpOnCrashdoes not generate a file and-XX:+CreateCoredumpOnCrashdoes not exist for the JRE. What version of Java are you using?Found the full error log for the frame regardless:
Will edit this when I find some possible root causes
EDIT: Whuh oh, something didn't play nicely with Xorg (X11), specifically the Swing library. The Swing library has caused me issues before with my own mod, but oddly enough, only in a dev environment. It happens shortly before trying to open a new window.
Tried with Eclipse Temurin, still got the error. hs_err_pid995795.log
Rebooting, updating drivers, etc. did not resolve the issue.
you can get a manual coredump if you're using visualvm which requires Graalvm to run
Which I got from the website https://rentry.co/JREs and by extension https://github.com/brucethemoose/Minecraft-Performance-Flags-Benchmarks
Try loading another modpack like Supersymmetry and see if the same crash occurs
Supersymmetry crashes upon loading because immersive railroading's URL leads to a site that got purchased and taken over, the file for the required version of the mod is gone. Thus, Mod Director breaks. Removing mod director and universal mod core does make it load, and it seems that Groovyscript loads just fine.
@Nrmot I have found that it is JFrame (though, this is not 100%, as in some cases, it will function just as expected instead of throwing the pthread error) that will cause this issue with Xorg, and thus, this is not actually Groovyscript's fault, but rather a scripting fault. I will have to look into your scripts to see if there's calls to make another window, and if I find it, this issue will be closed, hopefully with some documentation around Groovyscript telling scripters to avoid using JFrame for compatibility reasons.
I have no idea what is JFrame is but I am very sure there are no calls to JFrame in my script, unless I missed something...
alternatively you could try removing all the scripts from the base installation and try to run it
I have no idea what is JFrame is but I am very sure there are no calls to JFrame in my script, unless I missed something...
One of your modpack's mods calls JFrame, but it's not Groovyscript.
alternatively you could try removing all the scripts from the base installation and try to run it
I removed (renamed) the groovy folder, and still got the JFrame error. So, conclusion is that Groovyscript is not responsible.
There is a mod loading in right after Groovyscript loads in the scripts.
It's Not Groovyscript
The pthread error is being caused by a different mod opening up a window separate from the Minecraft process right after Groovyscript loaded the scripts, which made it look as if Groovyscript was responsible. It's time to look at what order the modpack loads the mods at and find the actual root cause.
Closing the issue.
UPDATE: To provide closure, it was found to be Modpack Config Checker being configured to open windows outside of Minecraft.