[FIXED 1.6.6] Biome decoration crash
JasonMcRay opened this issue ยท 17 comments
When player is flying through the End the server crashes with: http://pastebin.com/rA4GQBgT
If needed FML Server log i can provide it later, when i get home
HEE: v1.6.5
Forge: 10.13.2.1232
OK here is the FML log with the debug logging: http://pastebin.com/1jCxGwbH
Here is another report http://pastebin.com/FuLtwa8n
FML Log doesnt show much for me
[12:39:40] [Server thread/INFO] [FML/]: Unknown net.minecraftforge.common.chunkio.QueuedChunk {
x: -168
z: -25
loader: null
world: DIM1
dimension: 1
provider: chylex.hee.world.WorldProviderHardcoreEnd
}
[12:39:40] [Server thread/INFO] [FML/]: This should not happen. Please report this error to Forge.
[12:39:40] [Server thread/INFO] [FML/]: Unknown net.minecraftforge.common.chunkio.QueuedChunk {
x: -168
z: -25
loader: null
world: DIM1
dimension: 1
provider: chylex.hee.world.WorldProviderHardcoreEnd
}
[12:39:40] [Server thread/INFO] [FML/]: This should not happen. Please report this error to Forge.
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension 0
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension -1
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension 1
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension -28
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension -29
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension -30
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension 16
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension 15
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension -100
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension 14
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension 13
[12:39:47] [Server thread/INFO] [FML/]: Unloading dimension 12
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 11
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 10
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 9
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 8
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 7
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 6
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 5
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 4
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 3
[12:39:48] [Server thread/INFO] [FML/]: Unloading dimension 2
[12:39:48] [Server thread/INFO] [FML/]: Applying holder lookups
[12:39:48] [Server thread/INFO] [FML/]: Holder lookups applied
[12:39:48] [Server thread/INFO] [EnderIO/EnderIO]: ServerChannelRegister: Dimensional Trasciever data saved to /home/minecraft/multicraft/servers/BRLive/./world/enderio/dimensionalTransceiver.json
[12:39:48] [Server thread/INFO] [Galacticraft/GalacticraftCore]: Unregistered Dimension: -30
[12:39:48] [Server thread/INFO] [Galacticraft/GalacticraftCore]: Unregistered Dimension: -29
[12:39:48] [Server thread/INFO] [Galacticraft/GalacticraftCore]: Unregistered Dimension: -28
[12:39:48] [Server thread/INFO] [FML/]: The state engine was in incorrect state SERVER_STOPPING and forced into state SERVER_STOPPED. Errors may have been discarded.
the full FML log is 18 MB large. Its a public server so I cannot turn on debugging at this moment myself. Ill run it on test server in a little bit with debugging on
Sure, but the crash report is useless... I need the FML log with debugging enabled.
Anyways, I'm unable to replicate it in my own world (during testing I generated dozens of megabytes of chunks), so please try replicating the issue with HEE only. If you can't, then find whatever is conflicting.
That was the only log i have. No idea why the crash itself is not shown inside that...
I may or may not need to clarify that I deleted DIM1 each time I replicated the crash; it doesn't re-trigger in chunks that have already produced a crash.
Chylex same with me I booted up a test server with logging enabled generated a 400ish MB End Dimension could not replicate crash. Also on the public server from which I got the crash it was not a permanent issue and the same player in the same place could not replicate it ether.
I was able to get this crash reliably by flying directly west for about one or two minutes (after entering the End) from a level-seed=1 world (though you may need more to go on if your initial End generation isn't based on this).
Server Log: http://pastebin.com/0Hi2GLma
FML Server Log (Part 1): http://pastebin.com/tFCR0T3K
FML Server Log (Part 2): http://pastebin.com/FZiSbmKR
(Server) Crash Log: http://pastebin.com/q9hwGwvM
Interesting, this crash has some key information that was missing from other crashes, which actually does point to HEE code... and the FML log doesn't have the crash at all, so I guess sorry @JasonMcRay :D
Anyways, I think I have enough information now, so I'll get to debugging this thing. Thanks!
Was able to replicate the crash, but I will have to add a workaround for it because it's too random and unreliable - one in thousands upon thousands of chunks fails, so it's not really worth trying to come up a fix that will probably break at a different point anyways... There are no leaking chunks as far as I've noticed, so all it will do is just ignore the error.
Awesome thanks.
Just a question... will you do a ninja update of the 1.6.5, or will we need to wait for 1.6.6?
Wait for 1.6.6, I'll speed up the update though and move some things to 1.6.7. Will try to get this finished asap and release on Sunday.
Thanks, it worked.
The workaround appears to have fixed the much-more-frequent crashes with Cauldron, too.
I've been trying to do a compile of the current code (for checking if Cauldron still has problems with HEE), but Gradle's compiling runs into a wall with "public static final class LinkedKnowledgeObject T extends IKnowledgeObjectInstance extends KnowledgeObject T"
. The error given is "type argument T#1 is not within bounds of type-variable T#2". Do I need special parameters that aren't in the current build.gradle? Eclipse has no problems with it, but that isn't particularly useful.
@tgarr0 Pull latest commit and try again.