[1.6.4] Fireworks causing ConcurrentModification

[angellus]

First, I know have searched around a lot for this error and usually it is because the mod is poorly writen or the entity is being spawned on the wrong thread. As far as I know, either of those are happening here. I am creating and spawning the firework entity on the server side, not client side. The ConcurrentModification is seemly random, but only occurs when there is no block above the player (firework spawned at player's location).

 

Here is the crash log. It is for the server. The clients get read time outs for the server crashing.

 

And here is the relevant code. Along with the "helper" function to create the firework. I got the code to create the ItemStack for the firework from net.minecraft.ItemFirework (I think, it was a while ago, cannot remember). It generates a Firework with identical NBT tags as one Minecraft generates (tested with NBT explorer).

 

I am not sure if this is a Forge bug or me doing something wrong. Either way, some help would be great.

Thanks.

 

EDIT: One last thing, I know at about 150% certainty that THIS code is causing THAT exception. We have actually having this error for almost a Week now and we have tried everything we know to fix it. This is the most possible simplified version of the code that still causes the crash.

[TheGreyGhost]

Hi

 

I gather this error doesn't happen very often?  This exception occurs when the collection is modified (eg elements added or removed) while you are iterating through it.  So either the client thread is writing to this collection (trackedEntities), or you have done something in EntityTrackerEntry.tryStartWachingThis() that alters the trackedEntities.

 

Are you really, really sure that you're spawning the entity on the server side?

 

I'm not sure what the object 'this' is in your helper function, but perhaps .side is not correct?

If you put a breakpoint in your helper function just before the spawning, you could check the thread to make 100% sure it is the server thread.

 

Alternatively you might try putting a try {} catch {} block around the EntityTracker.func_72788_a(), and put a breakpoint in the catch.  If you are lucky, you might notice a pattern in what the client thread is doing at the time of the exception.

 

If the error occurs fairly often, you could add breakpoints in your helper, and also in the java.util.HashMap methods with modCount++  (eg  .put(K,V) ) - when the helper breakpoint occurs, enable the HashMap breakpoints and resume.

 

If it's fairly rare, you could perhaps create your own copy of HashSet but containing println methods to log all calls to HashMap methods which affect modCount, for example

 

    public boolean add(E e) {

        System.out.println("MyHashSet.add modCount" + map.modCount);

        return map.put(e, PRESENT)==null;

    }

 

Change trackedEntities to be MyHashSet instead of HashSet and with any luck the log will tell you exactly who the culprit is.

 

-TGG

[angellus]

  On 10/27/2013 at 10:27 AM, diesieben07 said:

It is important to know where the code that you call "relevant code" comes from. What is

this.player

? What is

this.side

? Where does that "relevant code" get called? You can only ever ever call it from the main minecraft thread.

 

this.player and this.side are exactly what you might think. They are initialized when this class is (when the player logs in). This class is for a player's "skill" (RPG-ish mod). So, this.player is the owning player of the skill (EntityPlayer). It is generated upon login for a player. Likewise, this.side is returned from "FMLCommonHandler.instance().getEffectiveSide()" and initialized when the class is; so this should only ever be running on the server.

 

Also, it does only run in the main Minecraft thread (it did not use to, removing it from its own thread greatly decreased the crash amount, but did not stop it). 

 

EDIT: That crash log is a server crash log. The clients get read time out errors.

[GotoLink]

You might want to try to spawn it away from the player.

[TheGreyGhost]

Hi

 

  On 10/27/2013 at 2:00 PM, angellus said:

this.player and this.side are exactly what you might think. They are initialized when this class is (when the player logs in). This class is for a player's "skill" (RPG-ish mod). So, this.player is the owning player of the skill (EntityPlayer). It is generated upon login for a player. Likewise, this.side is returned from "FMLCommonHandler.instance().getEffectiveSide()" and initialized when the class is; so this should only ever be running on the server.

 

Also, it does only run in the main Minecraft thread (it did not use to, removing it from its own thread greatly decreased the crash amount, but did not stop it). 

 

EDIT: That crash log is a server crash log. The clients get read time out errors.

 

When I put a breakpoint in addEntityToTracker, I see two relevant threads:

"Minecraft Main Thread"

and

"Server thread"

 

Your helper function must run in the Server Thread, not the "Main minecraft thread".  Perhaps you should try putting a breakpoint in there to make sure.

 

-TGG