MacOS JVM SIGSEGV Crash
I've been having issues with DH on my device, which gives the same crash on every beta build of DH (2.3.0, 2.3.2, 2.3.3). I isolated it down to it just being an issue between DH, Sodium, and Indium.
- DH runs by itself (just DH and fabric api installed)
- Sodium and Indium run by themselves (again just with fabric api)
- They also both independently work on the modpack I was trying to get them working on, again with either sodium + indium, or DH.
- Only crashes when sodium and Indium are installed alongside DH.
I saw one other post here about something SIGSEGV related, but it seemed like it was just for the alpha build, and other than that I haven't been able to find a related post similar to this issue, so I apologize if this ends up as a repeat.
I also tried Indium and Sodium versions down to sodium 0.5.3, and nothing has worked with that either.
Honestly, I don't know how to sift through crash reports, so I've used ChatGPT below to give a summary of the rest of the details if needed.
Minecraft Crash Report – JVM SIGSEGV
Fabric | 1.20.1 | macOS | Modded (Sodium + DH)
Crash Info
Crash Type: Native JVM Segmentation Fault (SIGSEGV)
Address: 0x0000000000000000 (null pointer)
Crashed Function: PhaseChaitin::elide_copy()
JVM Component: libjvm.dylib (Zulu OpenJDK 17)
Thread Crashed: C2 CompilerThread1 (JIT optimizer)
While Compiling: net.minecraft.class_3215::method_16155
Uptime Before Crash: ~29 seconds
System Info
OS: macOS Sonoma 14.7.5 (Intel, x86_64)
Mac: 2019 16” MacBook Pro (Intel i9, 64GB RAM, Radeon Pro 5500M)
Java Version: Zulu OpenJDK 17.0.16+8
JVM Heap: 16 GB (-Xmx16096m) — ~15% used at crash
Active Mods
Fabric Loader: 0.15.7 (for Minecraft 1.20.1)
Fabric API: 0.92.0+1.20.1
Sodium: 0.5.13
Indium: 1.0.36
Distant Horizons: 2.3.3b
Thanks for the help in advance.
Solution:Jump to solution
Shoot I hadn't seen that before. That seems to have worked though, thanks a ton
Is this a temp fix for now or is generic rendering just not going to be a thing on MacOS devices?
And is there much benefit gained from having generic rendering?...
33 Replies
isn't indium not needed anymore? also i might have an idea of what's going on, does it work without sodium?
btw actual game logs will be needed, those are the system logs by the jvm which aren't useful
1.20.1, its still needed
1.21.x doesn't need it
gotcha
I could give game logs, where do they go when a crash happens? (Game crashes as soon as you fully load into a world just fyi)
oh yeah we had seen issues like these before
there might be something you can do about it
Oh?
That'd be great, because I have two modpacks I'm managing that are on 1.20.1 and I'd really like to get them updated
try disabling instanced rendering in dh settings
Advanced options -> rendering -> generic rendering
https://discord.com/channels/881614130614767666/1380061124048719944/1380071618092597280
from that message and down
Oh I forgot to mention that I tried that before too, which is what gets me because that seems to fix most other people's problems on MacOS
oh
does it happen without sodium?
I get a fabric 'missing mod' error before the game boots when sodium or indium are removed and the other stays
but removing both of them at the same time lets DH work.
Thing is, I, like most people, kinda need sodium and indium
yeah, just checking if it's the same thing as the other ones
reproduce the crash once more, then head to the minecraft folder, then logs, and get the latest.log one uploaded to mclogs and then send the url here
!logstores
You should send your
latest.log file to provide additional useful information.
Logs are usually located in the .minecraft/logs directory.
On Windows: %appdata%\.minecraft\logs
On Linux: ~/.minecraft/logs
On Mac: ~/Library/Application Support/minecraft/logs
Please upload the file to mclo.gs instead of sending the raw file. This makes reading the contents of the file a lot easier and improves the chances of you getting the help needed.
After uploading the file, click on Save and send the link.I'll try to have a quick look but im on my phone which makes doing anything a pain in the rear
No worries
the log doesn't have much
so even after that instanced rendering thing it still does work?
but under that message i linked, someone had said it didn't work for them, and then someone else said to disable some other stuff and then it worked, did you try the "other stuff" too?
Solution
Shoot I hadn't seen that before. That seems to have worked though, thanks a ton
Is this a temp fix for now or is generic rendering just not going to be a thing on MacOS devices?
And is there much benefit gained from having generic rendering?
Sorry this ended up as a repeat.
i don't know
disabling those things is definitely gonna be far better than removing sodium, that's for sure
we don't know what's causing the issue but we believe it might be apple's crap opengl drivers
Yeah i've heard they're super outdated
they don't even reach full opengl 4.6 compliance, while nvidia fermi cards (like, gtx 400 and 500 series) can
that is sad wow
very
even on the x86 macs it is bad, in the arm ones it might even be worse because it's a completely different architecture but i don't know for sure
i wonder what vulkan conformance you have there
would be funny if there was something like zink which you could use
Oh i never got vulkan working lol Idek what zink is
it seems incompatible with this device
zink is an userspace driver by mesa which answers opengl calls via vulkan
i think it's only for linux as it's a mesa thing
but MacOS is also unix so i wonder if there's something similar. would be cool to experiment with
people usually use zink do dodge bad opengl drivers
wait how does it even do that
because if that's a possibility i might have to look into that
(side note, would the bad drivers still apply in bootcamp? or would the updated bootcamp drivers work with generic rendering?)
well i guess you could go to mesa3d.org and read the documentation on zink, maybe it would say more details about it. but like i said that was just an idea i have no idea if something like that is available on macos
idk what bootcamp is
oh, it's just apple's partition manager that allows you to dual boot windows and macos on intel macs
you mean like a bootloader?
pretty much
just it can only add windows alongside macos (and windows 10 at that, 11 you have to update to)
well updating that bootloader wont change anything on the macos drivers, but on windows that would become a regular laptop with an intel cpu and rdna1 amd card which should work 100% finw
i might just set it up there then if i actually need generic rendering then. Thanks for your help, i really appreciate it
gotcha
mark the thread as solved
on this message i think