Solved Entities stored in the wrong chunk? Odd?

Note: I am not entirely sure of this, I am just basing this on my observations.

Set-up: Have a plugin running with the following listener code:

PHP:

    @EventHandler(priority = EventPriority.LOWEST)
    public void onChunkUnload(ChunkUnloadEvent event) {
        Entity[] entities = event.getChunk().getEntities();
        if (entities.length > 0) {
            System.out.println("CHUNK: [" + event.getChunk().getX() + "/" + event.getChunk().getZ() + "]");
            for (Entity entity : entities) {
                Location loc = entity.getLocation();
                int chunkX = loc.getBlockX() >> 4;
                int chunkZ = loc.getBlockZ() >> 4;
                System.out.println("ENTITY: " + entity + " AT [" + chunkX + ", " + chunkZ + "]");
            }
        }
    }

Next, place a VERY LONG piece of powered railroad track from one end to the other. Place a block at the endings. Now, let a single Minecart move back and forth between these endings, and enter the Minecart.

In my case, I notice that some chunks contain entities from other chunks. For example, chunk [10, 18] unloads and it contains entities in chunk [10, 7]. I can not explain this behaviour, I can only somewhat observe it.

This does not happen on CraftBukkit. I am not running any plugins while testing this (TrainCarts is disabled).

EDIT

Yup, this is the easiest way to reproduce:


Place a long line of one-space-in-between minecarts and fly around it. Result:

Code (Text):

CHUNK: [10/21]
ENTITY: CraftMinecartRideable AT [10, 12]
ENTITY: CraftMinecartRideable AT [10, 12]
CHUNK: [10/20]
ENTITY: CraftMinecartRideable AT [10, 12]
ENTITY: CraftMinecartRideable AT [10, 12]

EDIT2

Unfortunately, it appears to be incredibly random. I can only hope someone has a clue what is going wrong...

 

Ok IGNORE THIS REPORT. I finally spotted the error after several days.

Code (Text):

        if (isLoaded && changedChunks && world.isChunkLoaded(oldcx, oldcy)) {
            handle.world.getChunkAt(oldcx, oldcz).a(handle, oldcy);
        }

Spot the error? Yeah, it's a sneaky little error, oldcy should be oldcz on the first line. It perfectly explains what this bug report shows. The bug was mainly caused by the unloaded-member ticking BKCommlib supplied, I assumed it didn't do anything, I was wrong.

All is well