pthread_mutex_lock+0x4 error that causes CTD

[Vetpetmon]

LATEST OBSERVATION: https://github.com/CleanroomMC/GroovyScript/issues/89#issuecomment-1751887765

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

[brachy84]

Can you please post your script?

[Nrmot]

ill provide the script since this person was playtesting my pack for reference

groovy.zip

[Vetpetmon]

Confirmed that this happens with other modded setups, even without GS scripts, all on the same OS.

[Nrmot]

must be a problem related to the same OS, try another OS

No idea if this is from Groovyscript side or Pop OS side

[Rongmario]

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.

[Nrmot]

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

[Vetpetmon]

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.

[Nrmot]

i would believe this crash is only possible if groovyscript was using an external library that did not work on linux for some reason

[Vetpetmon]

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: https://github.com/xerial/sqlite-jdbc/issues/509 and https://github.com/plan-player-analytics/Plan/issues/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.

[Nrmot]

@Vetpetmon try to test with an older version of groovyscript aka 0.5.x to see if the ctd issue is still there.

[Vetpetmon]

@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.

[Nrmot]

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

[KorewaLidesu]

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.

[Vetpetmon]

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.

[Vetpetmon]

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:

hs_err_pid992604.log

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.

[Nrmot]

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:

hs_err_pid992604.log

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

[Nrmot]

Try loading another modpack like Supersymmetry and see if the same crash occurs

[Vetpetmon]

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.

[Nrmot]

Aight waiting for an update for this

[Nrmot]

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...

[Nrmot]

alternatively you could try removing all the scripts from the base installation and try to run it

[Vetpetmon]

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.

hs_err_pid37234.log

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.