Crash on 32 bit JVMs: "Unable to bootstrap datafixers" due to stack overflow

First: sorry for the duplicate, I actually searched but there were so many "crash reports" that I overlooked this one. But I also failed to search for the keyword "datafixer".

I'd like to add that this also happens on 32bit environments and that I've ruled out a few options:

• I moved .minecraft out of the way to start fully fresh (no texturepacks for example) and that made no difference.

• I also tried skipping the shipped Java runtime but instead use a more recent version (1.8_161) and that also made no difference (still going to try SE9).

• And finally I changed some parameters to assign more and less memory, that too made no difference.

Hope this can help shed some light on this.

I am also experiencing this crash on Windows 7 with the same Java version as the OP (Java Version 8 Update 171 32bit). Is anyone experiencing this on 64-bit Java or is this a Java 32-bit issue?

It would appear to be a 32-bit issue. I follow Xisumavoid on YouTube, as well as a few other Hermits, and they seem to be able to load the snapshots perfectly. Seriously, Xisumavoid just put out a video highlighting the new 18w20a snapshots a few hours ago.

 Edit: I'm also running 32-bit Java on Windows 10. I've also reverted to Java SE 8 Update 111, and still got the same crash. 

Looks like we need to add 18w20b to the list of affected versions. Also, the launcher now crashes without adding the errors to the launcher log when you enable the "Open Output Log" option.

Me,too!

It looks like this exception is due to too many thread stacks, overflowing. And it's an type of out of memory. 

 -The minecraft is dosen't support old computer now.For a better computer. There is no other solution at this time. 

-    Add an -Xss1024K may fix you problem.

Impossible man. I got my laptop about 2 years ago

That's the thing: Minecraft would've thrown a java.lang.OutofMemory error if that was the case. Also, ShelLuser tested various memory set ups, and got no results. I can also run Forge mods–some fairly heavy-- on 1G RAM and they run just fine, if slow due to constant garbage collection. And another thing: We all were able to run 18w16a, which means our hardware setups can handle 1.13 when it comes out. But something went seriously wrong when updating to 18w19a+, resulting in in inability to even load the loading screen.

Let's add 18w20c to the list of affected versions.

Guys, I've just hit a workaround for the crashing issues.

In your launcher, go under the JVM arguments for the snapshots, and at the very end, add this argument:

-Xss1024K

This will increase the stack size and allow you to start running the new snapshots.

@unknown:This is a great finding.

On 32 bit JVMs the default stack size is 320k whereas on 64 bit JVMs the default stack size is 1M

Thanks! I'm glad I can help!

Also, you might want to change those G's to M's. We don't want to fry any processors by adding more stacks than they can support, now do we?

😛

Sorry, Kumasasa, but I have another edit for you. I've been messing around with the -Xss parameter in the launcher, and got the snapshots working at as little as 640K for stack size. 

Thanks!  My server jar would not run (same boothstrap datafixer crash) until I added -Xss1024K.

Think I actually have the 64-bit version of Java...

Minimizing the stack size probably isn't necessary (the difference between 640K and 1024K is fairly insignificant) and could lead to instability elsewhere (if there's something else that uses a lot of stack space), but it's good to know that that can work too.

You can check if you've got 64-bit java installed by running java -version; it should include "64-Bit Server VM" in the output if you have 64-bit java installed (and set as the default version; you might have both 64-bit and 32-bit installed and it's defaulting to 32-bit)

@Ray Allen-- You're welcome! And that is just bizarre, considering that 1024K is the 64-bit stack default.

@[Mod]Pokechu22-- I was just messing around with it after the 1024K modifier locked my game up trying to save and quit. At 640, I was able to save without issue, but the launcher crashed upon exiting. I'll play around some more at 1024 to see if the lock up occurs again. 

Add an -Xss1024K fixed my problem.

java -version gives me:
java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) Client VM (build 25.171-b11, mixed mode, sharing)

Oh, I guess I should say that my server is just on our home network, not the internet...

Update: Actually tried playing... It works! My kids and I have been unable to play together on our Aquatic world for over a week, but now we're back!

I can confirm that the -Xss1024K workaround has got the 18w20c snapshot working for me after it refused to work without it. Good find.

I'm glad to here that everybody's back to having fun with the new snapshots! 

I updated Java from 32 to 64, and it still crashes

Dawid: Did you add the -Xss1024K or -Xss1M argument into the JVM arguments box?

For some reason, this problem occurs because either Minecraft or Java defaults the stack size to the 32-bit default, which is 320K, when the game requires–at minimum in it's current state–640K stack size. So, in order to get the game to run, we have to force the JVM to utilize at least the 640K stack size, preferably 1024K for stability purposes.

This is why we need to add the -Xss1024K tag in the JVM arguments: it will force the game to allocate that much stack space, eliminating the stack verions of an Out of Memory error.

I added this argument after failed try to launching 18w20c with Java 64bit.

Did it help at all? 

@unknown, do you run Minecraft Client from the Launcher with the bundled Java or do you run a Minecraft server and you're starting maybe a different 32 bit JVM ?

I still can't figure out for sure if I have 64-bit, -version doesn't say.
Looks to me like SE is 64-bit only, so they stopped telling you?

Also, I can't figure out what my default stack size is...

Found a web page that said to type in this: java -XX:+PrintFlagsFinal -version

Doing so says:
intx ThreadStackSize = 0 {pd product}

This seems to be impossibly low...

Ok, think I have 32-bit version.
First, it is installed in C:\Program Files (x86)\Java
Second, I did this:
C:\Users\Ray>java -d64 -version
Error: This Java instance does not support a 64-bit JVM.
Please install the desired version.

No idea how this happened, since I have 64-bit OS and browser...

That is weird. Normally, Java downloads the appropriate version automatically.

Ok, seems I switched to IE to install because java doesn't work in Edge. Just learned that IE can have both 64-bit and 32-bit tabs depending on page content. Seems java's automatic detection decided I wanted 32-bit...

Maybe I should uninstall and reinstall 64-bit manually...

@unknown: No, not necessarily. Often the 32 bit version is being downloaded despite being on 64 bit OS.

@unknown: Uninstall all Java instances and download here https://www.java.com/en/download/manual.jsp the 64 bit version.

I had changed from 32 to 64, but it still didn’t work. Only way for me to make it work were adding this argument

I did manual install of this version from Oracle:
Java SE Runtime Environment 8u171 (64-bit)

Now, runs fine without the -xss

18w21a