md_5

This is a major issue and occurs whenever a chunk containing  a structure is completely empty.

Steps to reproduce:

Vanilla 1.15.2 Server:

level-seed=-987174934016447961

level-type=flat

/tp 224 6 -144
/fill 224 0 -144 239 10 -129 air

/stop

Update Server to 1.16.1

Observe error spam

Possibly related to MC-175169 but unclear if same cause (could be due to client/server using different randomness).

Looking at the code I think it was fixed at some point

Confirmed in 1.15.1.

1. Generate world with generate-structures=false

2. Spawn dolphin

3. Feed with fish

4. Game hangs

Thread dump:

"Server thread" #24 prio=5 os_prio=0 cpu=22878.07ms elapsed=104.70s tid=0x00007f8d0c92d000 nid=0x422d runnable  [0x00007f8c869ec000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
	- parking to wait for  <0x00000007fff63b70> (a java.util.concurrent.CompletableFuture$Signaller)
	at java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:194)
	at java.util.concurrent.CompletableFuture$Signaller.block([email protected]/CompletableFuture.java:1796)
	at java.util.concurrent.ForkJoinPool.managedBlock([email protected]/ForkJoinPool.java:3128)
	at java.util.concurrent.CompletableFuture.waitingGet([email protected]/CompletableFuture.java:1823)
	at java.util.concurrent.CompletableFuture.join([email protected]/CompletableFuture.java:2043)
	at caw.a(SourceFile:93)
	at cav.e(SourceFile:60)
	at wp.g(SourceFile:821)
	at wp.j(SourceFile:511)
	at wp$$Lambda$2247/0x0000000840752040.get(Unknown Source)
	at java.util.concurrent.CompletableFuture$AsyncSupply.run([email protected]/CompletableFuture.java:1700)
	at aip.h(SourceFile:144)
	at aip.v(SourceFile:118)
	at xb$a.v(SourceFile:550)
	at aip.c(SourceFile:127)
	at xb.a(SourceFile:136)
	at bjt.a(SourceFile:180)
	at bjw.a(SourceFile:108)
	at cfi.a(SourceFile:137)
	at bzx.a(SourceFile:107)
	at xd.a(SourceFile:1181)
	at atf$b.c(SourceFile:619)
	at aqs.c(SourceFile:41)
	at ape.a(SourceFile:75)
	at ape$$Lambda$2722/0x0000000840852440.accept(Unknown Source)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept([email protected]/ForEachOps.java:183)
	at java.util.stream.ReferencePipeline$2$1.accept([email protected]/ReferencePipeline.java:177)
	at java.util.stream.ReferencePipeline$2$1.accept([email protected]/ReferencePipeline.java:177)
	at java.util.stream.ReferencePipeline$2$1.accept([email protected]/ReferencePipeline.java:177)
	at java.util.stream.ReferencePipeline$2$1.accept([email protected]/ReferencePipeline.java:177)
	at java.util.Iterator.forEachRemaining([email protected]/Iterator.java:133)
	at java.util.Spliterators$IteratorSpliterator.forEachRemaining([email protected]/Spliterators.java:1801)
	at java.util.stream.AbstractPipeline.copyInto([email protected]/AbstractPipeline.java:484)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto([email protected]/AbstractPipeline.java:474)
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential([email protected]/ForEachOps.java:150)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential([email protected]/ForEachOps.java:173)
	at java.util.stream.AbstractPipeline.evaluate([email protected]/AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.forEach([email protected]/ReferencePipeline.java:497)
	at ape.a(SourceFile:69)
	at akx.du(SourceFile:633)
	at akw.k(SourceFile:2331)
	at akx.k(SourceFile:490)
	at akw.h(SourceFile:2173)
	at akx.h(SourceFile:295)
	at atf.h(SourceFile:260)
	at xd.a(SourceFile:600)
	at xd$$Lambda$2491/0x00000008407ba440.accept(Unknown Source)
	at bjt.a(SourceFile:534)
	at xd.a(SourceFile:398)
	at net.minecraft.server.MinecraftServer.b(SourceFile:847)
	at wd.b(SourceFile:343)
	at net.minecraft.server.MinecraftServer.a(SourceFile:786)
	at net.minecraft.server.MinecraftServer.run(SourceFile:654)
	at java.lang.Thread.run([email protected]/Thread.java:834)

It happens even more frequently in 1.15 because the ItemStack clone method was updated to return the EMPTY constant, so now it also shows up in places that were manipulating cloned stacks.

Can be reasonably reliably reproduced by just generating a few thousand chunks.

A ticking fluid checks if adjacent chunks are loaded, but for some reason the method that checks if the chunks are loaded ends up actually loading part of the chunk, which causes more things to be marked for ticking --> crash.

Ubuntu 19.10 also affected

Affects 13b, same steps.

Please search for duplicates, and then if not reported open a separate bug for each of those things.

Reopening as I'm still seeing this in 11b.

Stack is the same as before just with

sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)

At the top instead of yield.

Teleporting between worlds is the most reliable way to reproduce it (still not very reliable), but it definitely also happens just during the course of having a server played on for hours. Simply flying in a straight line even for extended periods of time does not reproduce it.

@nickovs most JVMs will not do nanosecond sleep, internally they will just round up to the next nearest millisecond if nanos is large enough.

See e.g. OpenJDK https://github.com/md-5/OpenJDK/blob/9ce194a08077f2d0d6acf034c3326b9a53baa14f/src/java.base/share/classes/java/lang/Thread.java#L325

Attached a crash report from 19w05a.

Appears that my comment is incorrect - its only one of several ways in which this can occur.

The freeze as per the title is also occurring randomly during normal chunk loads from various places, but I do not yet know why.

Reproduced on LAN world by joining a second player and quitting the host.

No error log is displayed (unless debug is enabled?), but the second players gets "Internal Exception: java.lang/StackOverflowError" when quitting.

Replacing yield with sleep(1) is a quick fix.

An even better fix would be to not use a busy loop and rather use futures or wait/notify.

Reproduction world attached - log in to coordinates t (491, 99, 523) to trigger the freeze.

Its due to a deadlock in the duplicate entity handling code.

How/why the entities duplicate is another bug, but in this case it appears to be duplicated cod/salmon.

Fixed at some unknown point

Resolved in 1.13

I'd like to propose a different fix that gets closer to the root of the issues and fixes it more broadly, namely:

1. Tile entities get added to chunks with mutable block positions that are then later changed by the converter, resulting in bad state

2. The ordering of access across chunks is not well defined, and the converter may run conversions back and forth across different pairs of chunks depending on how the bordering edges are populated (e.g. a chunk with tiles crossing over on all edges).

https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits/eea43870346d11b7f8cf6cc4bf516e406c3ec006

Thanks Mart!

I can confirm the same issue on my end - several of the chests are only half full in 1.13.1