I'm getting a pretty consistent crash loading my world for my current playthrough of Project Ozone 2. It seems like some sort of race condition because occasionally I can get my world to load without crashing.

java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
at java.util.ArrayList$Itr.next(ArrayList.java:851)
at buildcraft.core.lib.utils.CraftingUtils.findMatchingRecipe(CraftingUtils.java:78)
at buildcraft.factory.TileAutoWorkbench$LocalInventoryCrafting.findRecipe(TileAutoWorkbench.java:134)
at buildcraft.factory.TileAutoWorkbench$LocalInventoryCrafting.rebuildCache(TileAutoWorkbench.java:138)
at buildcraft.factory.TileAutoWorkbench.func_145845_h(TileAutoWorkbench.java:285)
at net.minecraft.world.World.func_72939_s(World.java:1939)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:111)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:396)
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)

Full crash report attached.

crash-2016-12-18_16.57.12-server.txt

This might be a duplicate of #3361 and it means that another mod is changing the recipe list while BC is iterating through it.

I don't have any idea what mod is doing this though, although something you might want to try is finding out which recipe the crafting table is crafting at (-934,87,82) and placing it down in a new world, then removing mods one by one (or a bunch at a time) until you no longer get the crash. This only works if you can get it to crash reliably on world-load though :/

The recipe is standard ExUtils 9x regular cobble to 1x compressed cobble hooked up to a ExUtil transfer node cobble generator with ExUtil piping on the input side. On the output side, it's thermal expansion piping into a vanilla chest.

However, it shouldn't actually be actively crafting anything as the internal buffer was full of compressed cobble due to the chest being full. I should also note that the world was technically loaded and the crash occurs during that initial "freeze" when you generally have lots of mods loaded.

If concurrent modifications can happen during that window and cause problems and since the exception backtrace seems to flow through code you control, is it not possible for you to catch the ConcurrentModification exception in CraftingUtils.findMatchingRecipe, re-fetch the recipe list and re-start the loop?

Unfortunately, since it is a race condition there is no easy way to troubleshoot by using a new world and removing mods since I can't trigger it on demand. :(

That makes sense, can you try running this BC jar instead of the current one (rename the current one to "buildcraft-7.1.18.jar.backup" or something like that), backup your world (as its an untested dev jar and I don't want to invalidate your world), and see what it throws in the log files? It doesn't fix the crash yet, but it does print out a list of the stacktrace of every thread. If we can't get anything from that then I'll build a different jar that won't throw an exception.

You'll have to rename this jar from ".jar.zip" to ".jar" as github doesn't like ".jar" :P

buildcraft-7.1.19-pre1.jar.zip

As I'm logging off for today here is the non crashing alternative. Note that this one might randomly clear the table's recipe whenever it throws, so please bear that in mind in the future. (although it still logs everything)
buildcraft-7.1.19-pre2.jar.zip

I had torn down the machine since it was the apparent source of my pain. :-D

I'll see if one of my recent world backups has the setup (or just set it back up again) and see if I can trigger the crash. Assuming I can, does this jar log someplace else or will it show up in the crash report?

At least that fixed it.

And no, it doesn't log in the crash report but it does in the most recent log file -- in the same minecraft folder directory there should be a folder called "logs" (alongside the "mods" and "saves" folders), which should contain an "fml-client-latest.log" file.

Party starts at line 24192

fml-client-latest.zip

Edit: Looks like minetweaker is still knee-deep in adjusting recipes for kappa mode when this happens?

minetweaker might indeed be the issue, if it is doing messing with recipes from a different thread (they did it in the past so pretty sure they still do it) while the list isn't threadsafe after the world has loaded it could indeed be cause of this

closing as this is another mod messing with recipes from the networking thread instead of the main thread

@AEnterprise Will the patch that was provided by @AlexIIL to work around this be applied to the 1.7.10 branch?

I realize that this isn't BC's fault but since it seems that MT is no longer maintained it makes the situation kind of difficult to deal with without you guys working around the bug in their code. :(

i am not sure how easy that would be, @asiekierka is doing the maintenance of 1.7.10 (also on 1.7.10 it's not the networking thread that's calling it but still another thread)

That's fair. Personally, I tend to lean more towards pragmatism when it comes to these unfortunate situations of working around other's code.

Just to confirm in case @asiekierka wants to consider this issue, the patched version that @AlexIIL provided with the debugging level turned up to 11 did work for me.

Edit: I speil gud

Unfortunately the patch was a bit of a hack around what was most likely a minetweaker bug, and I don't really want to fill 1.7.10 BC with hacky fixes.

For some reasons I never said this before, but the bug seems to be that minewteaker will send the client the updated minetweaker config, even if the client is an integrated client, which means that it is adjusting the same list as what the server uses. This should probably be reported to minetweaker, which could be a problem if its no longer releasing 1.7.10 versions.

the reason they do that (iirc) is that prevent server configs getting stuck when you swap from a server with different scripts to a singleplayer world

the main issue is that they are doing this recipe changing on a different thread while the world is already getting loaded around yout

i beleive this might be fixed for crafttweaker (minetweaker for newer versions) as there where problems with JEI and other mods when they where using the networking thread so it would have to be tested