Remove XU2 Sound Muffler - Frequent crash/lockup when exiting a Compact Machine
Opened this issue ยท 11 comments
tornewuff commented on Jan 3, 2019, 10:45 AM UTC:
Thank you for helping us improve.
Please follow the issue template, and do not delete any part of it.
Failure to comply will result in the issue being closed.
Issue Description
About 50% of the time when exiting a compact machine (using the personal shrinking device), the game will lock up hard on returning to the overworld, rendering only the skybox and no blocks, and not responding to any input. Looking at the logs, the game has actually crashed with this exception:
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
at com.rwtema.extrautils2.tile.XUTile.searchAABBForTiles(XUTile.java:102)
at com.rwtema.extrautils2.blocks.BlockSoundMuffler.supressSound(BlockSoundMuffler.java:59)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_1828_BlockSoundMuffler_supressSound_PlaySoundEvent.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
at net.minecraftforge.client.ForgeHooksClient.playSound(ForgeHooksClient.java:366)
at net.minecraft.client.audio.SoundManager.func_148611_c(SoundManager.java:352)
at net.minecraft.client.audio.SoundHandler.func_147682_a(SoundHandler.java:258)
at net.minecraft.client.multiplayer.WorldClient.func_184134_a(WorldClient.java:477)
at net.minecraft.client.multiplayer.WorldClient.func_184156_a(WorldClient.java:462)
at net.minecraft.client.renderer.RenderGlobal.func_180439_a(RenderGlobal.java:2419)
at net.minecraft.world.World.func_180498_a(World.java:3703)
at net.minecraft.world.World.func_175718_b(World.java:3694)
at net.minecraft.world.World.func_175655_b(World.java:412)
at appeng.tile.networking.TileCableBus.onReady(TileCableBus.java:224)
at appeng.hooks.TickHandler.onTick(TickHandler.java:220)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_2508_TickHandler_onTick_TickEvent.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
at net.minecraftforge.fml.common.FMLCommonHandler.onPostServerTick(FMLCommonHandler.java:266)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:712)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:185)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526)
at java.lang.Thread.run(Thread.java:748)
However, the game then also usually gets stuck trying to exit cleanly after the crash, causing a hard lockup: the client thread never quits (or releases the mouse cursor from the game window). I managed to flip to a tty and dump the thread stacks with jstack; the client thread is stuck here:
"Client thread" #1 prio=5 os_prio=0 tid=0x00007f50a800d000 nid=0x6fa in Object.wait() [0x00007f50aec2c000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1252)
- locked <0x0000000642885e40> (a net.minecraft.client.main.Main$2)
at java.lang.Thread.join(Thread.java:1326)
at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:107)
at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
at java.lang.Shutdown.runHooks(Shutdown.java:123)
at java.lang.Shutdown.sequence(Shutdown.java:167)
at java.lang.Shutdown.exit(Shutdown.java:212)
- locked <0x00000006413ace00> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(Runtime.java:109)
at java.lang.System.exit(System.java:971)
at net.minecraftforge.fml.common.asm.transformers.TerminalTransformer$ExitVisitor.systemExitCalled(TerminalTransformer.java:138)
at net.minecraftforge.fml.common.FMLCommonHandler.handleExit(FMLCommonHandler.java:501)
at net.minecraft.client.Minecraft.func_71377_b(Minecraft.java:777)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:408)
at net.minecraft.client.main.Main.main(SourceFile:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:196)
at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:231)
at org.multimc.EntryPoint.listen(EntryPoint.java:143)
at org.multimc.EntryPoint.main(EntryPoint.java:34)
I don't know which thread it's joining on, and it may not be related to the original crash at all.
Modpack version (Do not use "latest")
1.46
I've also had the crash occur in several earlier versions of the pack. I'm going to update to the latest shortly and will see if it still reproduces there.
I've also added three mods locally: Cloud Control, Crafting Tweaks, and PackagedAuto (though I've also had the crash before I added PackagedAuto). I think it's probably safe to assume these aren't related though?
Logs
If applicable, please upload your crash report, or latest.log to hastebin.
Crash log: https://hastebin.com/etefizozil.rb
jstack thread dump after the game locks up: https://hastebin.com/uzalozocok.pl
Screenshots
If applicable, add screenshots to help explain your problem.
Can't screenshot after the game hangs alas.
Additional context
Add any other context about the problem here.
I took a look at both the XU2 and AE2 github issue trackers and couldn't find this on either.
I looked at the source code for both mods too (I'm a pretty good programmer, though I'm fairly new to MC modding): it's not very clear to me exactly what AE2's TileCableBus.onReady is doing, but in the case that it crashes, it's decided that the cable bus in question is "empty" and as a result to call World.destroyBlock on something, which is suspicious in itself because nothing in my network should be being edited/removed at that point (I'm still travelling between dimensions, not doing anything to AE, and I'm in singleplayer).
Destroying the block then generates a sound effect, and XU2's sound muffler block class is registered as an event handler for all generated sounds so it can check if there's a sound muffler near the sound's coordinates (this happens globally, even if you don't have any sound muffler blocks anywhere in the world, since it's part of the actual BlockSoundMuffler class, not part of the corresponding tile entity). It finds all the chunks near the sound and iterates over all the tile entities in those chunks checking to see if any of them are both close enough and actually a sound muffler, and during this iteration is when it crashes - one of the tile entity maps has been changed while it's doing this.
The BlockSoundMuffler code itself isn't causing the concurrent modification, as it doesn't do anything else with the tile entity map other than iterate over it reading - this suggests that the modification must be happening on a different thread (which seems bad; the world isn't threadsafe in MC, right? Only the server thread is supposed to access it?)
One more thing I'm unsure about here is that this is the server thread on which this is happening, and the AE2 code is a server side tick handler... but the sound playback and XU2 code all appear to be things that should happen on the client side? The BlockSoundMuffler.supressSound method is even marked @SideOnly(Side.CLIENT).
It's not clear here whether this is a bug in XU2, or in AE2, or in some other mod in the pack that's adding/removing tile entities from the world from some other thread, so I'm reporting it here for now :(
This issue was moved by NillerMedDild from NillerMedDild/Enigmatica2Expert#534.
NillerMedDild commented on Jan 3, 2019, 12:41 PM UTC:
So that was fun to read :P
I need to do some testing of my own on this, specifically seeing if it can be reproduced on Windows, I'll keep you posted.
tornewuff commented on Jan 3, 2019, 3:56 PM UTC:
I can zip up my world later on if you can't reproduce it. I'd guess you need to have some amount of AE system complexity in the overworld for it to trigger (my system is pretty big, I'm using something like 450 channels with a load of p2ps). I think, though I'm not sure, that it only triggers if you have spent "a while" inside the compact machine before leaving - if that's actually true then I guess it's to do with things being reloaded in the overworld... but my entire base should be chunkloaded (via the ftbutils map) so there shouldn't be any parts of the AE system that need to be reloaded at that stage.
I doubt that the actual crash is Linux-only, but the specific way the client thread locks up afterwards might well be, and the specific way it screws up my machine in the process certainly is - Minecraft uses an X11 mouse grab when it has focus and you're not in a GUI, and X grabs stay in effect even if the window loses focus, so alt-tabbing out of the hung game doesn't give you your mouse back. I don't think Windows has that particular crappy behaviour :) I'm making sure I leave a terminal open when running MC now, so that if it happens I can alt-tab to the terminal and "killall -9 java"...
NillerMedDild commented on Jan 3, 2019, 5:26 PM UTC:
Ouch, that doesn't sound good. I wonder if it can reproduced by traveling from The Nether to your base, through nether portal.
tornewuff commented on Jan 3, 2019, 5:56 PM UTC:
I've not been to the nether in a while, I don't remember that happening. I also haven't had the issue while using an RFTools advanced charged porter to teleport to/from other planets/space that I can remember either. :|
NillerMedDild commented on Jan 4, 2019, 6:34 PM UTC:
Does version 1.48a remedy your issue tornewuff?
tornewuff commented on Jan 5, 2019, 12:56 AM UTC:
I updated to 1.49 yesterday but I haven't actually played the world for more than a few minutes; when I get a chance at the weekend I'll try to reproduce it again, and if I can I'll experiment more with different ways of teleporting around to see which ones trigger it, and upload my world for you to test.
tornewuff commented on Jan 5, 2019, 5:03 AM UTC:
Reproduced on 1.49 by going into a compact machine, waiting around for a while, and then hopping back out again - crashed and locked up the first time I tried. Link below is a zipped copy of my world just after the crash; if you load it up you should be standing in my basement next to the compact machine in question. Hop back in there, wait around for like 3 minutes, then try to come back out and see if it crashes for you too.
(I added PackagedAuto to the pack so it'll probably give you the missing registry entry warning but it should be fine to just click through and let the blocks get deleted, the crash has been happening since before I added that mod).
https://drive.google.com/file/d/1tZsKKoORdj7GEugYzrL8SjWKqW11TGFg/view?usp=sharing
Google Docs**[Lupinia.zip](https://drive.google.com/file/d/1tZsKKoORdj7GEugYzrL8SjWKqW11TGFg/view?usp=sharing&usp=embed_facebook)**
Google Docs
Grobes commented on Jan 5, 2019, 11:42 AM UTC:
I had this bug. Many hours of testing and I came up with a solution. The crash happens on moving dimensions and I believe is ultimately related to the EU2 Sound Muffler
"at com.rwtema.extrautils2.blocks.BlockSoundMuffler.supressSound(BlockSoundMuffler.java:59)"
despite me not having any sound mufflers in the game it would still crash.
To stop the crash happening, simply go to the Extra utilities 2 config and disable the Sound Muffler block. No more crashes!!. Does however stop you completing that quest.
Hope this helps although it does not really fix the problem.
tornewuff commented on Jan 5, 2019, 12:09 PM UTC:
...yes, that makes sense. As I said in the initial report here, the sound muffler event listener is global, not per-tile-entity, so having the block object created at all is enough, but I didn't think to check if there's a config option to disable that device and whether it actually skips creating the block entirely.
So, yeah, I'm still not sure that XU2 is even doing anything wrong here and it might be some other mod that is touching something it shouldn't that breaks it, but it helps to just play the game in the meantime (having it crash more isn't generating any new information, since the stack is always the same).
The XU2 sound muffler is much less flexible/useful than the one from Super Sound Muffler anyway, though, so Niller, you could just drop the quest for the XU2 one and disable it for everybody if you think it's worth it?
NillerMedDild commented on Jan 5, 2019, 12:27 PM UTC:
I'll see if disabling it helps :D
NillerMedDild commented on Jan 5, 2019, 3:08 PM UTC:
Oh my apologies, I somehow missed Grobes comment. I will disable it and remove the quest.