Fabric: Ticking Entity/NullPointerException on breaking block.

[Keoxxa]

When breaking a block, doesn't matter what nor what tool used, occasionally the game will CTD. This seems random. Takes either 20 seconds or 2 or more hours, but the crash-log is always the same.

I am using a very large modpack, with around 240 mods.

Due to the inconsistency, I'm unsure if this is only axesareweapons or a mod incompatibility. I simply don't have the time to run a second world with only axes are weapons installed for several hours. If I find a day off I might try it but someone with more free time can comment if they can get around to it sooner.

gobberGetBlockBreakingSpeed is also mentioned, so it may be an incompatibility issue with Gobber. Disabling cobwebminingspeed does not seem to solve the issue. Disabling Gobber seems to fix it? I couldn't test it for very long. Only got about 30 minutes in. Further testing might be required.

https://pastebin.com/9Rp1eF1Q Crash-log without disabling Gobber.

[Fourmisain]

Oh no, this one again. This was previously an issue on Forge, likely due to a coremod, I thought - and hence I thought this would never be an issue on Fabric.

I've took a look at almost all Mixins into class_1792 (= Item) from your crash report but couldn't find any conflict. Gobber seems fine too.

What modpack are you using? It'd be easiest for me to just install it and look at the produced bytecode.

[Keoxxa]

I've disabled gobber and played it a bit more, didn't crash yet. I've put about 2-3 hours in now.

I don't know what else could be causing the issue, maybe something from artifacts? I didn't have anything equipped on a few of the crashes, though.

It's currently a custom massive rpg modpack I've been working on. I don't know if it'll appear in search, so I'll upload here for you. First time uploading one so let me know if I need to check more things for export.

5 mods should be disabled: aspects, basic shields, RPG difficulty, RPG-hud and You're-in-grave-danger as these have conflicts I'm waiting on updates for. Gobber on or off depending on what you want to test. With on is when I've had it crashing. Only turned off Gobber recently though. For difficulty I'm on hard, picking vampire, butcher and water as my origins. keep inventory enabled might be ideal if you want to test this combo out or creative mode in an umbrella for yourself.

It really is such a random crash that it's rather hard to test. It either appears right away, or very late in into playing. I've gotten the issue both while mining a dirt block with my fist 20 minutes into a world, and 2 hours in mining a lantern with an iron pickaxe.

Maybe a decent rpg thing that wont break this time maybe.zip 240 + mods, but I have it in pretty stable condition. The cobwebminingspeed crash has been the only crash stopping things lately. I'm aware of the issue with immersive weathering in the logs, but I've been trying to gather info on it's impact before reporting it. From what I can tell it just bloats logs, but not enough to really matter. Sorry I can't be more help, but if I get the crash again with Gobber disabled I'll let you know.

[Fourmisain]

Okay, new findings, kind of.

tl;dr I walked through the decompilation and found that this crash is independent of Axes Are Weapons, it should happen with or without it. Disabling fast cobweb breaking should show the crash happening in another class like class_1766. Gobber still doesn't look like it causes the crash. In fact, none of the mods of the current modpack do, the crash seems impossible given the code - which could mean that a different mod set was used when it crashed. (Do you have a crash report for the current mod set?)

Or there are still some ASM shenannigans which aren't captured in the mixin bytecode dump?

Nitty gritty: Your crash report starts ends here in Item.getMiningSpeedMultiplier():

My Mixin code here simply sets axesareweapons$state = $$1 (a BlockState) on the first line and in the second line uses that state to potentially change the block breaking speed of 1.0. In your crash report, it crashed because axesareweapons$state was null, which is only possible if the argument $$1 was null to begin with. Note that this would only crash at this place if fastCobWebBreaking is set to true - it won't check the state otherwise.

The thing is, even the vanilla MiningToolItem's or SwordItem's getMiningSpeedMultiplier() expects that BlockState to not be null, so you should still get crashes without Axes Are Weapons. You might already have a crash report that points e.g. to class_1766 when you disabled fast cobweb breaking.

The question is, why is the block state null in the first place? There has to be a mod either modifying the value on the way or manually calling one of the methods with null.

I've walked through the stack trace and got stuck.

NullPointerException: Cannot invoke "net.minecraft.class_2680.method_26204()" because "state" is null
at io.github.fourmisain.axesareweapons.common.AxesAreWeaponsCommon.overrideCobWebMiningSpeed(AxesAreWeaponsCommon.java:21)
at net.minecraft.class_1792.constant$bfc000$cobWebsAreSpeed(class_1792.java:554)
at net.minecraft.class_1792.method_7865(class_1792.java:198)
at net.minecraft.class_1799.method_7924(class_1799.java:272)
at net.minecraft.class_1661.method_7370(class_1661.java:413)
at net.minecraft.class_1657.handler$gge000$gobberGetBlockBreakingSpeed(class_1657.java:32901)
at net.minecraft.class_1657.method_7351(class_1657.java)
at net.minecraft.class_4970.method_9594(class_4970.java:383)
...

Going bottom up, we start at method_9594 and end at the top, where the state is null. method_9594() begins with:

So a method was called on the block state $$0 without causing a NullPointerException, meaning it couldn't have been null at this point.

Walking through the decompilation, that block state is then directly passed to method_7351, from there it is directly passed to gobberGetBlockBreakingSpeed, then to method_7370, then to method_7924, and finally to method_7865 - where it is null according to the stack trace...?!

There's nothing actually changing the passed state, so I have no idea what is going on.

One thought is that the crash report used a different mod set. Checking those 5 disabled mods, Basic Shields was enabled in that crash report, though I heavily doubt that this is related; the mod only has 3 simple Mixins, none related to mining.

So uh... Do you have a crash report with the current set of mods? Because it does look like a crash is impossible with the current set of mods (or at least it would crash at a different point).

[Keoxxa]

Interesting, 12/5 should be the latest crash report as don't think I've changed anything since then BESIDES disabling gobber and adding 2 irrelevant mods and so I don't have another crash report as I've not crashed since disabling it. I didn't even update any mods at the time. So that should be the current set of mods from the crash report. I have more from 12/4 and 12/2 with the same crash report and same mods, and the very latest ones were a levelz issue that has been fixed.

The latest modpack I sent has had 2 new mods since after the crash (I think), bonezone and baubles, but those shouldn't be affecting anything. Basic Shields should be disabled as it had issues with levelz's restrictions. Something I was looking for a workaround to, it's been disabled for ages and shouldn't be enabled at all, so something wonky is going on if it is appearing as enabled as it's been disabled for me. I know it's not causing any crashes though, just had balancing issues.

But if I'm understand things correctly, it's something being thrown around incorrectly, returning null for no real reason? Something weird is going on with the modpack then. Maybe it's just things getting overloaded? Too many bounces for java?

Either way, thank you for getting a look at it. Sorry to bring it to your attention if it's not this mod causing the issue, it's very hard to tell what is doing what when the crashlog/log isn't all that helpful and this apparently is a crash that's out of the crashlogs bounds to tell me what's going on. Doesn't help I'm not the most java savvy person. Saw yours at the top and thought it was involved in a way that was more than just catching the error. At least now I know to run stuff through a decompilation for better issues, I'll try teaching myself how it all works.

I also had a weird error with origins in this pack that had a similar result, shouldn't be doing anything, but was. running 4 of a specific origin setup with aspects was bloating log files massively (2k kb per couple minutes.) The log was claiming it was another mod throwing null when it was actually 2 different mods conflicting. So this isn't the first time it had me bothering an author that wasn't involved in an issue with a weird "shouldn't be happening" error.

I apologize again, sorry for wasting your time. But thank you massively for looking into it. This entire breakdown is very helpful in figuring out what's going on and so I can test a few more things. If it is java being overloaded, disabling the extra bounce from Gobber or this mod should fix the issue. If not I can look at more things though.

I'm going to keep gobber disabled and see if it still crashes, then I'll try keeping fast cobweb breaking off if it does so I can see a different error that might help, but it really sounds like I was just overloading what java can do.

Either way, I won't bother you more about the issue as it seems your mod is only catching the error I'm having, not causing it. Thank you again.

[Fourmisain]

At least now I know to run stuff through a decompilation for better issues, I'll try teaching myself how it all works.

Nah, you're a player, you report bugs, I'm a dev, I debug stuff and fix bugs, a crash report is usually more than enough to find the cause of an issue - though in this case, this same issue (#7, #9) eludes me to this day.

... Wait a second, I only just realized that it was you who reported this same bug on the Forge side as well :smile:

I also had a weird error with origins in this pack that had a similar result, shouldn't be doing anything, but was. running 4 of a specific origin setup with aspects was bloating log files massively (2k kb per couple minutes.) The log was claiming it was another mod throwing null when it was actually 2 different mods conflicting. So this isn't the first time it had me bothering an author that wasn't involved in an issue with a weird "shouldn't be happening" error.

Yeah, all the different Origins mods modify the game in a deep manner, so there's often conflicts with other mods. Most of the time, conflicts are stuff like Mixin conflicts where you immediately know "oi, that Mixin doesn't go with that Mixin", but sometimes the modification of one mod can result in weird unintended behavior in another mod, which is harder to catch and debug.

But if I'm understand things correctly, it's something being thrown around incorrectly, returning null for no real reason? Something weird is going on with the modpack then. Maybe it's just things getting overloaded? Too many bounces for java?

By "too many bounces" you may be thinking of a stack overflow due to too deeply chained function calls, but no, this is not that, Java would throw a StackOverFlowError in that case and those are super rare. This is just a logic bug, except that it seems to be invisible. All I've really shown is that there's something we're missing.

Either way, thank you for getting a look at it. Sorry to bring it to your attention if it's not this mod causing the issue

It could still be a mod conflict with a mod using ASM. I saw for example that Twilight Forest has some references to ASM, though I don't see a conflict there either. ASM could explain why the logic bug seems invisible. If ASM works after Mixin, the ASM changes won't be visible in Mixin's bytecode dump.

So it might make sense checking mods that are also on Forge and more likely to be using ASM in the first place.

This entire breakdown is very helpful in figuring out what's going on and so I can test a few more things. ... I'm going to keep gobber disabled and see if it still crashes, then I'll try keeping fast cobweb breaking off if it does so I can see a different error that might help

Usually, a very good method find mod conflicts is to disable half of all mods, test if the issue is still there, and if not, you know the issue has to come from that disabled half. Then you reenable half of that, retest, and if the issue is back, it's from that enabled half. Rinse and repeat until you're down to your conflicting mod/s. This works extremely well for issues that are fast to test, but since this is a rare and random issue, it's sadly not very reliable. :disappointed:

Since this is not the first time this error popped up and it's not yet resolved, I'll reopen this issue, because I want to get it resolved too.

[Keoxxa]

Alright, do let me know if there's anything I can do to make your job easier then. I've updated all mods now (about 10 updated in the last couple days) and updated to fabric 14.11, kept the usual disabled and Gobber too. Created a new world and just going to do a usual playthrough on it. I'll slowly go through and disable suspected mods if crashing keeps happening, I'll try to report back here if I find anything. No news means no crashes, at least none related to this issue.

Also, yeah usually I would do the disable half thing and re-enable until I figure it out, but as you said, such an inconsistent crash means that would likely take me months to narrow everything down, sadly. I'll still try to do that if I can narrow things down enough.

I did report the forge one, but I was still on fabric then. I think I misread/misunderstood the fix, thinking both the fabric and forge was mixed on both sides. Looking at it now, it was just forge having the fabric mixin and not vice versa. Guess that was lucky then, and even more lucky was not getting crashes for several days after that. So I'm guessing that was the same issue then that it is now. That one also has the Gobber break speed in it, so I'm still suspecting Gobber of being one too many things or playing weird but I'm very not sure though. Needs more testing to narrow things down.

[Keoxxa]

Did get another crash, no gobber this time. https://pastebin.com/xuB6TQus Latest crashlog, same modlist as the one I linked, just fully updated besides fabric shield lib (version FabricShieldLib-1.6.1-lite-1.19.jar as the latest crashes at launch) and aspects. Maybe this one can be a little more help on what to disable?

[Fourmisain]

Hm... yeah, that report is basically the same, it again crashed inside my ItemMixin. I could actually delete that one, since I noticed it is completely redundant. I don't think that would solve the case though, since you said the game crashes even with fast cobweb breaking turned off.

I've gone through the whole mod list and checked some potential causes,

PlayerEx, Doodas and Balm all play with block breaking speed, though I again can't see an issue with them.

Bewitchment and Charm are both very large so I did not check them - though at least on 1.18.2 I can confirm that Charm isn't an issue.

My suspicion still mainly lies on big Forge mods like Twilight Forest, though you probably don't want to disable this in your world.

I think it could be helpful to understand more about the crash, so I've written a debug version which checks the block state in every method in the stack trace - that should narrow it down more. This version will log a ton and will show you a chat message when it is about to crash - I've patched it to not crash inside my code but it might crash anyway. If you got a message or another crash you can send me the logs/latest.txt - it might be too big, so you can simply send at the last few hundred lines or so on pastebin.

P.S. I also tried to evoke a crash with your modpack by spam clicking and using haste 255 for about 15 minutes, to no avail sadly.

[Fourmisain]

P.P.S. I removed the ItemMixin in the new 1.6.4 version - maybe that'll help afterall.

[Keoxxa]

I've been using the debug version since last week when you sent it, but I can't seem to get another crash. I've been updating mods regularly and disabled fabric shield lib as it was causing a startup issue. Otherwise it's been the same, with some added new ones that shouldn't be touching anything block breaking related. When the 1.6.4 version comes out I'll swap to that one and remove the debug and report if it crashes again at all. If it does crash I'll swap back to the debug one, or an updated debug one, and see if I can get it again.

So far so good since I disabled the other and started using the debug version. Hopefully not a case of "a watched pot never boils" though.

[Fourmisain]

https://github.com/Fourmisain/AxesAreWeapons/issues/12#issuecomment-1399294276

This is finally fixed for good, it was a threading issue of another mod causing a very rare race condition on the field I was writing/reading from. I have no idea why my brain took so long for going from "rare illogical bug" to "threading issue", but in any case, case's closed!