[MC-93655] Game crashes when a fireball is shot

After hearing that the mob inter-aggro AI had finally been updated I tested pigmen to see if they again would attack other mobs that hit them.

It worked for the skeletons, however when struck by ghast/blaze fireballs they did not respond. Shortly after the game crashed. This happens almost every time I try to test this scenario though sometimes not right away. With ghasts it sometimes took about 10 seconds to finally crash but it did multiple times with both mobs

The crash log said that it was caused by a null pointer for a fireball. My guess is the pigmen are aggroing on the fireballs rather than the ghast/blaze that shot them? Then the game crashes when the fireball disappears.

To replicate:

with spawn eggs create a ghast/blaze. Summon a group of zombie pigmen. Set yourself to survival and stand behind the pigmen so the incoming projectiles hit them. The pigmen do not make an angry sound or aggro on the mob that shot even if they are within reach. from 1-10 seconds later the game will crash. I was on mavericks version of the mac version of minecraft if that makes a difference.

Description: Ticking entity

java.lang.NullPointerException: Ticking entity
	at aaa.a(SourceFile:44)
	at zu.m(SourceFile:117)
	at ahn.a(SourceFile:1467)
	at lp.a(SourceFile:719)
	at ahn.g(SourceFile:1445)
	at ahn.k(SourceFile:1335)
	at lp.k(SourceFile:552)
	at net.minecraft.server.MinecraftServer.D(SourceFile:625)
	at net.minecraft.server.MinecraftServer.C(SourceFile:553)
	at bxz.C(SourceFile:154)
	at net.minecraft.server.MinecraftServer.run(SourceFile:457)
	at java.lang.Thread.run(Thread.java:745)

Linked issues

is duplicated by 11

MC-93762 Game crash when attacked by blaze Resolved

MC-93787 Fireball Ticking Entity Crashes Server Resolved

MC-93806 Playing,found a nether fortress,fighting blazes and suddenly black screen CRASH REPORT IN FRONT OF ME Resolved

MC-93877 Blaze Fireballs Cause Crash Resolved

MC-93965 Blaze Fireball vs Shulker Crash Resolved

6 more links

relates to 1

MC-93808 crash on approach to blaze spawner Resolved

Attachments

Crash-Report.rtf

Ticking Entity.txt

Comments 20

[Mod] redstonehelper 2015-12-02T21:16:03Z

Please attach the crash report.

Dan Midgett 2015-12-02T23:06:40Z

this is the crash report from where I made a blaze shoot a fireball that hit a pigman. The game immediately crashed. This also happens, but less reliably, with Ghast fireballs.

Warren Liddell 2015-12-03T23:40:15Z

Can confirm on my server 15w49b and will continually crash each time affected user in area re-joins server

Shadow_of_Doom 2015-12-04T13:45:34Z

Can conform. On my world, each time a blaze fires a fireball, the game crashes. Problem is, the game auto-saved at the point of crashing, causing my world to be un-playable, until this bug gets fixed of course.

Warren Liddell 2015-12-04T20:28:59Z

Shadow_of_Doom It onloy keeps crashing due to a player joining the game at the point of where the crash occured, if you manually edit that particular players player file an remove there current x/y/z cords the server will be playable, least untill such time as someone else goes into the nether.

Im surprised there isnt a c snapshot to fix this issue

10 more comments

Robin T. 2015-12-06T11:14:07Z

Can confirm what those guys say!

Jayden 2015-12-07T08:13:53Z

The crash seems to have nothing to do with zombie pigman at all. For me as soon as the blaze summoned the fireball the game crashed immediately.

Warren Liddell 2015-12-07T21:10:26Z

Your completely right, its more when a fireball is shot that the crash occurs regardless of who or what its aimed at

marcono1234 2015-12-07T21:36:54Z

The reason for that seems to be the life tag. For the fireballs which are causing the crash it is set to 0. Eventually the game removes them instantly because their life value is 0 but tries to update them after that. Setting this value with external tools to something different prevents the game from crashing.

See also MC-87456

No Name1 2015-12-07T22:04:49Z

Use this.

/entitydata @e[type=Fireball] {life:1}

It should work.

Skylinerw 2015-12-08T06:15:38Z

@Marcono1234, "life" is not related. 600 is when it's intended to unload, not 0 (but cannot do so naturally anyway).

I could not replicate the crash until I changed the mobGriefing gamerule to true. I could also not replicate it with a blaze alone; the crashes only occurred when the fireball collides with an entity that is immune to fire (pigmen, blaze, magma cubes, etc).

The "NullPointerException" error typically occurs when a null value was found where an object was expected. The "aaa.a()" function is called when the fireball hits either an entity or block. Pseudo example:

onImpact(FireballCollisionData)
{
    if (FireballCollisionData.theHitEntity != null) {
    
        // Do entity-based code, which seems to not be used for fire-immune entities since mobGriefing isn't used here
    } else {
        
        // Do block-based code
        
        boolean canPlaceOnGround = true;
        
        if (this.shooter != null && this.shooter instanceof EntityLiving) {
            
            canPlaceOnGround = mobGriefingGameruleValue;
        }
        
        if (canPlaceOnGround && isAirBlock(FireballCollisionData.getBlockPos.getOffset())) {
            
            placeFireOnGround();
        }
    }
}

The problem looks to be at "FireballCollisionData.getBlockPos.getOffset()", implying "getBlockPos" is null. Judging from 1.8 MCP, BlockPos will only be null if an entity was hit, and "theHitEntity" is only null if a block was hit. This implies that an entity was indeed hit, but the passed entity into the FireballCollisionData was null. I imagine that the fire-immune entities are passing null rather than their class, but I'm no expert with the source (and even less so with Java).

Skylinerw 2015-12-08T06:29:34Z

@No Name, please do not comment for the sake of arguing, especially if you're only intending to state false information that will not help resolve the issue. If you have something to contribute to fixing this bug, please do.

Walter van den Berg 2015-12-08T14:22:54Z

@NO Name1 tried that fix, reproduced the bug as stated in the bug description. It crashes, still. (worlds especially made for this, in 15w49b)

Edit: Seems like the original comment is missing. I was referring to turning mob griefing off, not ot the @e command.

Anomie X 2015-12-08T23:56:31Z

@Skylinerw: In 15w49a the second line of the pseudocode you quote changed to something along the lines of FireballCollisionData.theHitEntity != null && !FireballCollisionData.theHitEntity.isImmuneToFire(), probably as the fix for MC-70327. But since, as you noted, FireballCollisionData.getBlockPos is null when the fireball hit an entity, it breaks when it gets into the other code path.

Sir Lord Jeff 2015-12-09T17:25:57Z

Tested it in 15w50a and I didn't crash, can anyone else confirm it's been fixed or did I get lucky?

Edit: Checked the source code, it has been fixed.
The previous code (renamed by me so I can understand it better)

Old Source

if (!this.world.isStatic) {
    if (movingObjectPosition.entity != null && !movingObjectPosition.entity.isFireproof()) {
        //Code to ignite an entity was here
    } else {
        //Code to place fire on the block the fireball hit
    }
}

The new code (again, renamed so I can understand it)

New Source

if (movingObjectPosition.entity != null) {
    boolean bl;
    if (!movingObjectPosition.entity.isFireproof() && (bl = movingObjectPosition.entity.damage(DamageSource.fireball((EntityFireballBase)this, (Entity)this.hit), 5.0f))) {
        //Code to ignite the entity
    }
} else {
    //Code to place fire on the block the fireball hit
}

As you can see in the new code for placing fire only runs if the fireball didn't hit any entity

Skylinerw 2015-12-09T17:33:38Z

I can no longer reproduce it either.

Simba 2015-12-09T17:37:27Z

Can't reproduce, seems fixed.

Mustek 2015-12-09T17:38:29Z

Marked as such.

No Name1 2015-12-10T09:33:29Z

It IS FIXED! Do you guys even view snapshot changelogs? Supposed you didn't, cause you all say that "Can't Reproduce", view that changelog, here: http://minecraft.gamepedia.com/15w50a#Fixes .

user-f2760 2015-12-10T10:20:11Z

@unknown the reason its on the page is because since nobody could reproduce, a modderator marked it as fixed, the wiki is not an official source and keeps updating all the time. Since they saw that this was marked as fixed (by the modderator) they added it to the fix list