GitLab

https://mclo.gs/A4RR2zR (https://pastebin.com/3RRtpAr1) – ConcurrentModificationException happens when I spawn more than one entity and rejoin the server or warp back to the world, this includes stuck parts of the entity or the stuck whole entity at the location (of the entity) at join/warp while the same entity is walking around normally starting at the location with the stuck parts.

NullPointerException – not sure whats triggering it in detail but also called when I spawn multiple entities and rejoin or warp back to the chunk sometimes. Result: the underlying vanilla mob and the custom model is visible at the same time while moving around in the world.

Test entity is the viking_NPC made by LittleRoom, so I would expect it to work well. (Meanwhile tested it with a lot other LittleRoom resources from Patreon, same problem everywhere.)

Software	version
Paper	1.19.3 build 380
MythicMobs	5.2.1, fd1d0777, premium (no dev version)
ModelEngine	R3.1.3

Server Version: org.bukkit.craftbukkit.v1_19_R2 (Paper)

Happens on different test server unrelated to other plugins. If this is a MythicMobs related problem, please let me know and I will move the report.

Possible duplicate #32 (closed) and #33 (closed)

changed the description

changed the description

changed the description

I have some idea about the concurrent modification error, but I couldn't figure out why the null pointer error occurs. Do you have a consistent way of triggering it?

added Bug label

I tested that again and actually could trigger 3 problems – However I can not tell if they are related to each other.

1. Stuck copy of a model (mob)
2. MountManager.canStear NullPointerException (underlying mob becomes visible)
3. ConcurrentModificationException (not sure what causes this one)

All in common will be triggered only if a player leaves the chunks and comes back or reconnects. In the video you will see the live console left and the behavior in game right: https://resource.ofunny.world/dev/buga.mkv

I commented the video, so audio might be recommended. Hope that helps, if you need anything else just let me know. (Btw. if the filesize is too big, let me know and I render it to a smaller resolution.)

Can you test with the latest version (R3.1.4) to see if it fixes the first and third issues? Can you also test if that MountManager NPE occurs even with this build?

I tested the latest build and it appears that something changed from a subjective none scientific point of view.

1. Stuck copy of a model (mob) – No difference, still happens. The mob still works but a copy of some mobs sometimes stays stuck in place.

2. MountManager.canStear NullPointerException – Still happens, but it seems like it happens way more often if you logout/login or tp (chunk unload/load) fast and repeatedly after each other. Maybe there is some unresolved race condition or data not yet available when the thread tries to read it? But also sometimes it does not happen a long time in a row and than suddenly again, maybe also related to a certain state or code execution that must be met in the right moment to cause it.

But I could no longer find a mob with the vanilla equivalent (e.g. Iron Golem) visible at the same time, so that might got partially fixed or I just failed to trigger it or its unrelated to this exception and I was wrong in first place.

3. ConcurrentModificationException – It looks like it happens way less often, in my whole test the last 30 minutes I was just in able to trigger it once. While it happened much more often while testing on the last version – but this could also be a coincidence.

If there is anything I can provide to help you, just let me know.

Can you tell me how you triggered the stuck model problem? Before the update, it was triggered by repeatedly entering and exiting the render radius of a model while it was dying, which should be fixed in this build.

For the mount manager problem, is your mob using 2 model mechanics on different triggers? Like using model mechanic with onSpawn and onLoad? Otherwise I have no idea why the code being in the same thread would get race conditions.

Would be nice if you can tell me where that one concurrent modification error happened as well.

Would it help you if I just send you the whole testserver as archive or grant you shell access to the test installation – otherwise I guess this might be a hell of work to sort it out for you?

mentioned in issue #41 (closed)

ok, i move here as i have same problem with same mob! But for me only happens with this mob. Next to it i have 4 more different zones using different mobs (inlcuding mobs made by literom) and no error will show up at all. Can be this problem linked to this specific pack?

Heres the error: https://pastebin.com/xKJHW5Sp

Viking NPC with over 700+ random variations! (so it will spawn vikings having different models, with sword, with axes, different colors.. etc) not sure if u ned this info, i add it just in case. https://gyazo.com/62abb1a051eb1f8ae6fd6a4811f18c44

It's not only a Vikings problem, had issues with others too. But we may compare problematic configs to identify similarities if Tixco can not track the issue.

I think the NPE is stemming from some packs using both onLoad and onSpawn triggers at the same time to apply models, causing some sort of race condition. I believe the Viking NPC you're talking about is from LittleRoomDev? He's the only pack maker I know that uses both onLoad and onSpawn.

Can confirm that, I also saw that on more recent mobs from his Patreon. He is using

[onSpawn](#onspawn) When the mob spawns
[onLoad](#onload) When the mob is loaded (spawning or loading after a restart)

(Source: https://git.mythiccraft.io/mythiccraft/MythicMobs/-/wikis/Skills/Triggers)

for the same mobs with identical code in the trigger lines – since I suppose that he has tested that well, is this a left over from an older Meg or MythicMobs version where both needed to be called and obsolete now?

As far as I understand the MM wiki "onload" would include "onspawn" anyway, so it appears to be not necessary to call both with the same code. That's why I do not totally get the point why he is doing that. Anyway is it possible to catch that case if somebody oversees it in the configs?

Both triggers might be included because of some older MEG versions causing problems with loading models on spawn. You're right that onLoad includes onSpawn so it's obsolete, and after consulting Ashijin he said it is possible that using both triggers would create race conditions.

Still, this is just a theory since I cannot replicate the error (be it my device is too bad or too good)

What would be the recommended next step - removing onSpawn and testing it all again?

You create a new server instance, you put in only 1 pack or just 1 mob, do whatever you did to trigger the error, and see if the double trigger is the cause.

I will test that either tomorrow or this weekend, sorry for the delay but I'm packed with things on my todo list – will get back to you as soon as test have been completed.

So I removed the onSpawn lines now (kept onLoad) for one test mob – result:

1. Stuck copy of a model (mob): No difference, still happens. The mob still works but a copy of some mobs sometimes stays stuck in place when you rejoin the world or teleport back to the location from somewhere else (see video I made).

2. MountManager.canStear NullPointerException: Still happens here and there (see video I made).

3. ConcurrentModificationException: Could not trigger it again in my tests! However, leavening away the "onSpawn" event and only keeping "onLoad" will just show the underlying mob (e.G. Golem) with a nametag until you rejoin/teleport to the location to trigger onLoad (so no cust models will be shown on spawn) – so it fixes the ConcurrentModificationException somehow, but is still not a real fix since it breaks the mobs on spawn – for some reasons onLoad does not really handle onSpawn well, even if the MythicMobs wiki says so (either a bug or wrong information in the wiki, fix needed).

I'm not sure if that is also a MythicMobs problem or Meg only – I would also create a bug report for MythicMobs if that's the case. Except of that I can just repeat myself, do you need my pack, do you need my server as copy for local testing or do you want access to the testserver (shell and sftp)?

Because that back and forth here is really time consuming and I really would need a fix slowly after months of waiting (first on the slime fix trident, hitbox fix and now this), don't wanna sound impatient but it would be really nice if we could make some progress. Thank you

Where are the videos?

Also, progress is slow because we're at the stage where most bugs are so obscure, conditional, and rare. If I can trigger those bugs myself or have error logs for those (still waiting for the error log of the conmod error,) I can work on them much quicker.

If you still think I'm too slow, well, sorry not sorry. I have a life outside of this. I'm already giving my best effort to maintain the plugin while dealing with many other things.

"Where are the videos?" same video from 2 weeks ago, the behavior is the same except "ConcurrentModificationException" as explained one post before.

"error log of the conmod error" - is this something I missed and still should supply?

About the rest: I'm a dev and I can hardly imagine how you would be in able to bug fix the issue with Meg if you can't replicate it (as you wrote). Now I offered you multiple times already, that I either could send you my configs or pack or the server as a full zipped download (local testing) or even give you access to it with a brief explanation on how to trigger it, what you actually just ignore each time – so we continuously moving back and forth and still get nowhere.

Trust me, I also have a live outside and still willing to provide you with everything you might need to have an easier job finding the issues, you just need to let me know what you need. I mean it's closed source, can't expect me to inspect the implementation as well. :)

Attach your setup and also the stack trace of the conmod. I'll look at it tmr.

Hello again, heres the error on my test server, i cannot replicate the conditions, but on my live server same error happens all the time. https://pastebin.com/dwfksZvD

DUnno if it helps somehow.

Heres another pastebin, im not even on the server, actualy nobody is! https://pastebin.com/aTj0yv6M

What do you mean by "conmod"? I prepared a testserver (archive) for you, however I just see that I'm unable to reproduce the "ConcurrentModificationException" and "NullPointerException" on my local machine, what is almost incidental to my server. I still get the stuck models but no exceptions yet.

So either this is really related to AMD/KVM or my local CPU is too fast (what I can hardly believe) since the major difference is an Intel I7 13700KF on my local machine versus an AMD Epic via KVM on my server. I will try to verify that somehow. R3voolt can you share more details about the system you are using to trigger the exception (OS, java, hardware, etc)?

Maybe I'm also just super unlucky with testing and it just did not happen yet locally.

Using pterodactyl/ubuntu/ovh dedicated server, AMD Ryzen 7 3800X

Closing due to inactivity.

closed

Sorry, had to take some time off to take care of some familiar matters.

I've now updated to ModelEngine version R3.1.5 and MythicMobs version 5.2.5-SNAPSHOT-d6328fd0 and I couldn't throw neither the ConcurrentModificationException nor the NullPointerException - it looks like whatever you or the MM developers did, also solved these problems. But I was only able to do some quick tests today, I'll test it more extensively within the next week and get back to you with the results.

What still remains a problem are the "stalled models". However, since they disappear when you re-enter the server, I'm assuming they are leftover armor stands where the respective client has simply not been notified about their removal. I could create another ticket just to resolve this issue if desired.

reopened

So far the exceptions are gone – still the stuck model issue happens every time, I will open another issue for this tomorrow because I really need a fix for it and fear it might get lost here.

mentioned in issue #69

closed