Missiles cause segmentation fault / crash when target no longer exists.

[antonspace]

Observed behaviour

When an enemy ship is targeted, and guided missiles (guided, smart or naval) are fired at the target, if the ship is destroyed with less missiles than were fired, the missile / missiles that no longer have a target cause the game to crash within a few seconds after the ship is destroyed (segmentation fault). not yet tested with unguided rocket.

Expected behaviour

I would expect the guided missile that no longer has a target to carry on in a straight line until out of radar range.

Steps to reproduce

1. Target enemy ship
2. If targeted ship type is usually destroyed by 3 missiles, fire 4 missiles.
3. Wait until ship is destroyed, the game will crash soon after.

My pioneer version (and OS):
ab4f2ba
Linux Mint 64bit

[impaktor]

Without thinking too hard, this reminds me of #887, which I'm not sure ever got a good fix.

[jaj22]

I can't replicate this, so there's probably something about your test environment that's different from mine. Can you provide a savegame with target & missiles ready to fire?

[antonspace]

No problem, here is a savegame where the targeted ship requires 4 naval missiles to send it to the shipyard in the sky, fire 5 naval missiles, and the game crashes every time.

Another bug which happens often is well demonstrated here, my ship is carrying 6 naval and 6 smart missiles, when the first naval missile is fired using the on screen display, the number of smart missiles suddenly goes from 6 to 1.
Often the onscreen missile display disappears completely and the m key has to be used instead (but not in this example).

_quicksave.zip

[bszlrd]

@antonspace Could you create a separate issue for the UI problem?

[jaj22]

Ok, the crash triggered with my setup when I left it running and went to dinner. Apparently this is a bug introduced during the Missile/Ship class separation. Missile::OnDeleted does not pass the event on to the AICommand, and so the AIKamikaze target is never set to null. It doesn't crash until the target memory is eventually reassigned to something that it can't handle, hence the environmental dependence.

Should be an easy fix. I'll knock up a pull request later.