hang on 'waiting for chunk' and/or fatal background exceptions when teleporting to new chunks in a busy gameloop

Sorry that this report is so ugly, but I've spent a few hours trying to construct a 'minimal' repro, but this bug is 'intermittent' and it's hard to pin down the conditions that cause it to happen.

To attempt to reproduce this bug:

• Go into the attached world (almostMinimalRepro.zip)
  (there may be a lot of debugging output spewing out of the gameloop function)

• do "/function test:init", this will bring you into a lobby with a couple signs

• right click the "Join TEAM red" sign

• right click the "START game" sign

EXPECTED:

You will be teleported to a random location in the world (e.g. X=193000,Z=258000) and terrain will generate around you.

ACTUAL

(1) It may work. If it does, do "/function test:init" and then right click the "start game" sign again; eventually it will fail.

(2) The game may hang in "waiting for chunks" state, where you client sees you falling into the void and no terrain generates and you cannot interact with the server. You'll probably have to kill the client with Task Manager.

(3) The game output log (that appears from the game launcher) may feature various 'fatal' errors of this format:

14:37:35	net.minecraft.server.MinecraftServer	Error executing task
java.util.concurrent.ExecutionException: java.lang.NegativeArraySizeException: nbits < 0: -1251572160
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:192)
	at i.a(SourceFile:138)
	at net.minecraft.server.MinecraftServer.w(SourceFile:636)
	at net.minecraft.server.MinecraftServer.v(SourceFile:592)
	at clf.v(SourceFile:152)
	at net.minecraft.server.MinecraftServer.run(SourceFile:	497)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NegativeArraySizeException: nbits < 0: -1251572160
	at java.util.BitSet.<init>(BitSet.java:159)
	at blm.<init>(SourceFile:22)
	at blm.<init>(SourceFile:17)
	at aqr.a(SourceFile:1019)
	at aqr.a(SourceFile:1124)
	at aqr.a(SourceFile:1108)
	at zc.a(SourceFile:636)
	at rd.a(SourceFile:524)
	at kz.a(SourceFile:126)
	at kz$b.a(SourceFile:18)
	at hg$1.run(SourceFile:13)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at i.a(SourceFile:137)
	... 5 more

Notably, however, the game does not ever crash, so there's never an actual crash log.

NOTES

I have tried to minimize the repro steps more, but the more I minimize, the less commonly it seems to reproduce. (Race condition under load?) Feel free to ask for more info about the handful of functions in the datapack.

The last "significant" operation, which is essential to the repro, is teleporting the player to far off chunks. I have been unable to reproduce this unless the teleport happens in a function called by a gameLoopFunction that's also running other stuff.

EDIT:

I had a brainstorm to change from a gameLoopFunction to a single repeating_command_block that calls the function. Things still similarly fail, except now I get a different fatal error in the log:

Error executing task
java.util.concurrent.ExecutionException: java.util.ConcurrentModificationException
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:192)
	at i.a(SourceFile:138)
	at bmx.b(SourceFile:780)
	at bmx.a(SourceFile:380)
	at net.minecraft.client.main.Main.main(SourceFile:140)
Caused by: java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
	at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
	at ud.<init>(SourceFile:27)
	at bcd.<init>(SourceFile:92)
	at bcd.<init>(SourceFile:80)
	at bwz.d(SourceFile:54)
	at bxe.b(SourceFile:167)
	at bxb.a(SourceFile:660)
	at iq.a(SourceFile:96)
	at iq.a(SourceFile:18)
	at hg$1.run(SourceFile:13)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at i.a(SourceFile:137)
	... 3 more

That one is probably a more useful stack trace fragment, I imagine.

(As an aside, I am pretty sure this was present in 17w48a as well; I don't know if it existed before that.)