Jetpack smoke particles recurse until OoM (probably)
thePalindrome opened this issue ยท 13 comments
version 4172
This bug is still being triaged locally, but it's related to the jetpack smoke (as far as we can tell)
-- Head --
Stacktrace:
at java.util.Arrays.copyOf(Arrays.java:3181)
at java.util.ArrayList.grow(ArrayList.java:267)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:241)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:233)
at java.util.ArrayList.add(ArrayList.java:464)
at net.malisis.core.util.chunkblock.ChunkBlockHandler.getAffectedChunks(ChunkBlockHandler.java:328)
at net.malisis.core.util.chunkcollision.ChunkCollision.getCollisionBoundingBoxes(ChunkCollision.java:76)
at net.minecraft.world.World.func_72945_a(World.java:1443)
at net.minecraft.entity.Entity.func_70091_d(Entity.java:596)
at net.minecraft.client.particle.EntitySmokeFX.func_70071_h_(SourceFile:53)
-- Particle being ticked --
Details:
Particle: EntitySmokeFX, Pos (47.35904335230589,53.82000005245209,290.2964394291242), RGBA (0.12577984,0.12577984,0.12577984,1.0), Age 1
Particle Type: MISC_TEXTURE
Stacktrace:
at net.minecraft.client.particle.EffectRenderer.func_78868_a(EffectRenderer.java:77)
I'm working to find things... The smoke seems to be from a torch out in nowhere. We've been noticing it occurs while one of us are using our jetpacks (I have a Vectored, the other two have Builders). This last crash was with Particles set to minimal, XmX set to 4 gig, and nominal pack allocation being 1.3 gig.
Again, working to triage
Even after removing malisisdoors and core, still having issues with the smoke particles, running it through a cpu sampler is showing net.minecraft.entity.Entity.doBlockCollisions is consuming Everything. The fact I don't see any subcalls makes me think that it's recursing into itself, which is... weird.
Here's a snapshot I took (had to zip it to make github happy I guess). Showing the call list ( I tend to use https://mcp.thiakil.com/ to convert intermediate names and the names people use :P )
While I couldn't get the sampler mod to work in the dev environment, I could reliably replicate freezes by simply spawning particles with immense downward momentum (sideways momentum would most likely cause a freeze one layer deeper when trying to get the intersecting chunks) due to the amount of blocks being checked. While I can't explain how a particle would get this much momentum (without the player who's using the jetpack having the same speed which would also cause issues [come to think of it, depending on how speed on the client is handled, perhaps it has something to do with teleporting?]). I still added some checks both limiting the absolute speed of the particle being spawned and checking for any NaN values (just to make sure).
In addition, particle settings now affect jetpacks, removing the ground dust and smoke on "decreased" or lower, as well as completely removing jetpack particles on "minimal". If the previous fix didn't work, this should definitely allow you to avoid the issue entirely, assuming it really is the jetpack's exhaust particles.
at net.malisis.core.util.chunkblock.ChunkBlockHandler.getAffectedChunks(ChunkBlockHandler.java:328) is the last entry of the stacktrace before the ArrayList that ends up crashing. Seems to be either a compat issue or simply a bug caused by the Malisis core mod. Since the crash is cut off I can't tell what the actual exception type is, but form the offending line I can only assume that the crash is either caused by the ArryList's underlying array somehow being null or the list being so large that the list's size overflows into negative numbers.
Could you check what blocks are near X:47 Y:53 Z:290? I've been reading through both vanilla's and MalisisCore's code, and while I'm not exactly fluent in ASM I think the cause is that the particle collides with a block that has a bounding box that is infinitely big. Usually that would cause weird movement behavior but due to Malisis' added checks this could lead to a never ending loop that ends up killing all available memory.
Whether NTM is involved in this at all is hard to tell, personally I doubt it since the jetpacks use vanilla particles with a fixed relative downward momentum, and I have yet to see a scenario where that would lead to infinite bounding boxes. Unless of course there's some kind of block that expects smoke particles in particular to always have an upwards momentum and for whatever reason behaves incorrectly when smoke moves downwards.
Yeah, the closest I'd been able to come up with is that maybe an absurd amount of smoke particles are being spawned?
While I can tell that during such instances most of the tick time is being consumed by just moving smoke particles around (on clients, the server seems to be fine). I couldn't work out how to track what was creating said smoke particles, but I do feel that malisis is more or less innocent here and its inclusion in the stacktrace is just because of the hooks it has.
If you have any suggestions on how I could track this down better, let me know!
There is a hard limit on particles, and it's so low that it's almost impossible to crash your game because of it. You can easily see this in action, go into a creative world and get the laser detonator (the uncraftable one that has gun stats), and then load it with safe mini nukes. After about a second of continued fire, you'll see the first mushroom clouds disappearing (and before you ask, it's a feature).
As for the infinite bounding box theory, it stems from the fact that infinite bounding boxes are actually used in some places (mostly for frustum checks, i.e. whether things are within the FOV) combined with what I could make from MalisisCore's code, which iterates over every chunk that intersects with said box, adding it to a list (which unsurprisingly is the entire map + an infinite amount of empty chunks).
While I don't think I can do anything about it with what we know so far, I could add blocks with purposefully broken bounding boxes and run some tests with those.
The blocks at that position would imply that it would be torch smoke, but particles was set to "Minimal" (so the torch shouldn't have had particles, no?), and it's a ways down from the torch.
The reason I'd suspected too many smoke particles was because it seemed to be a torch's smoke particle, but with it being a ways down and your "infinite bounding box" theory makes me wonder what sorts of oddities are involved
Well there goes my theory, particles just move through the broken blocks (or seemingly all blocks), while aiming at the block causes the game to freeze without OoB after half an hour, so no apparent memory leaks here either.
Has this crash happened more than once? For all we know it might be caused by something entirely different. What other mods are you running?
1.7.10
AppleCore-mc1.7.10-3.1.1.jar
appliedenergistics2-rv3-beta-6.jar
BetterBoat-1.7.10-1.1.0.jar
Bookshelf-1.7.10-1.0.4.187.jar
buildcraft-7.1.23.jar
ChickenChunks-1.7.10-1.3.4.19-universal.jar
CodeChickenCore-1.7.10-1.0.7.48-universal.jar
Controlling-1.7.10-1.0.0.jar
craftingtweaks-mc1.7.10-1.0.88.jar
DynamicSurroundings-1.7.10-1.0.6.4.jar
FastLeafDecay-1.7.10-1.4.jar
GlibysVC-1.7.10-0.6.2a.jar
HBM-NTM-.1.0.27_X4172.jar
LunatriusCore-1.7.10-1.1.2.21-universal.jar
malisiscore-1.7.10-0.14.3.jar
malisisdoors-1.7.10-1.13.2.jar
mod_voxelMap_1.7.0b_for_1.7.10.litemod
Morpheus-1.7.10-1.6.21.jar
NotEnoughItems-1.7.10-2.1.7-GTNH-universal.jar
OpenComputers-MC1.7.10-1.7.5.1290-universal.jar
OpenModsLib-1.7.10-0.10.1.jar
OpenPeripheralAddons-1.7.10-0.6.jar
OpenPeripheralCore-1.7.10-1.4.jar
OpenPeripheralIntegration-1.7.10-0.6.jar
Schematica-1.7.10-1.7.6.131-universal.jar
Thistle-1.7.10-1.1.0.jar
VoxelMods
Waila-1.5.10_1.7.10.jar
Wawla-1.0.5.120.jar
There's my mod list, this has happened repeatedly to three different people (including myself) with different hardware configurations.
(the oddest mod there is "Thistle", but that's just an addon for OC that adds a custom cpu architecture, the rest should be fairly well known)