After quickly skipping over the code I noticed several problems with the implementation, potentially also causing issues elsewhere:

• The transformer code accesses a lot of outside classes, causing the accessed classes to be loaded during the transformer instantiation or invocation, which the architecture in launchwrapper doesn't handle well. E.g. all the Type.get_(_.class) invocations shouldn't be in there, but use string literals or asm-package-local constants.
• The edits are anything but minimal, best practice is to only insert a method call with the required locals grabbing + minimal post processing (only return, jumps or local var edits). This call then invokes a normally compiled method with all the implementation code.

I've found something likely related to this. When pressing "r" on flux gas in NEI (even though I know there's no recipe), I get this crash: http://pastebin.com/amb3bUhd

@superreg, can you upload the full client log from an instance where you have reproduced that crash? The stacktrace in that crash log doesn't seem to have anything to do with AppleCore.

That's btw. the crash reporter itself crashing, rather non-conclusive to debug. It's usually up to Forge to fix this first, but I doubt they'll patch it at this point.

https://drive.google.com/file/d/0B-TzDzva0D_YdUd6NXMwdTM3blk/view?usp=sharing

The part that seemed related was the Class transformer null safety: found misbehaving transformers: squeek.applecore.asm.TransformerModuleHandler(squeek.applecore.asm.TransformerModuleHandler@7d109ed2) crashed with java.lang.NullPointerException(null).

Thanks for the full log, I noticed that part of the crash log as well. Seems like this might be a false alarm, as there is nothing in the log that indicates that there was actually a problem with the AppleCore transformer.

I'll try to reproduce it myself, though, to make sure.

Closing this as the points in the OP have (mostly) been addressed: All outside class references have been removed from the ASM transformers and the largest ASM modifications (to FoodStats.onUpdate) have been moved to compiled code.

I know this is old, but i would like to add that recently in 1.12.2 the mod Oversaturation was the cause of my eating and crashing.

I'll put my vote in for this ticket, having read #17 and #18 and found the same problem. Is this a big job?

It's not trivial. Not sure when I'll be able to get around to it.

Alright, take your time, then. Sounds like something to be done carefully.

I've managed to get around this by only having FastCraft on the client and ForgeEssentials on the server. It is a pretty random thing to come across, isn't it?