Source Code Project Mantis - FSSCP
View Issue Details
0002652FSSCPgameplaypublic2012-05-16 12:332012-07-01 21:21
Assigned ToValathil 
PlatformOSOS Version
Product Version3.6.14 RC5 
Target Version3.6.14Fixed in Version 
Summary0002652: Bombs on destroyed subsystem causes crash.
DescriptionI've now reliably encountered this on RC6 as well as Trunk.

If a bomb is targetting a subsystem on a ship, and that ship/subsystem is destroyed before the bomb impacts it, it will sometimes try to target that same subsystem, but on a different ship.

So, for example, a bomb is fired. It is targetting turret07 on Ship A. Ship A or it's turret07 is destroyed before the bomb makes impact. The bomb starts looking for a new target and chooses Ship B, but then tries to target turret 07 on Ship B. The problem is that Ship B doesn't have turret 07.
Steps To ReproducePlay a mission with lots of bomb action? It's somewhat random because such specific events need to occur.

I'm trying to find a retail mission where it happens most often.
Additional InformationI once traced through the code with Valathil and Goober when this first happened. That's what showed that the bomb was targetting a subsystem that doesn't exist on a new ship.

It was originally with custom bombs, so I used the flag "no subsystem homing" which solved the crash.

Just recently I encountered it with retail bombs.
TagsNo tags attached.
Attached Filespatch mantis_2652.patch (557) 2012-05-20 16:39
7z BombTestCrash.7z (539,669) 2012-05-21 00:05
patch mantis2652.patch (7,709) 2012-06-08 06:21

2012-05-19 23:38   
What is the correct behaviour in this case?

Should the bomb go dumbfire when its target is destroyed? Should the bomb self destruct? or Should the bomb attempt to lock another target?
2012-05-20 08:12   
My guess is that it really just needs some error checking. If subsystem is not found on the current target, find a new subsystem.

That coupled with if the current target is destroyed, be sure to clear all current targeting data including the subsystem.
2012-05-20 16:25   
I think I have found the cause. What type homing weapon is this, heat or aspect? IIRC retail bombs are all aspect seekers.
2012-05-20 16:29   
Yeah, they are aspect seeking.
2012-05-20 16:41   
Please try with the attached patch. It should make all homing weapons drop their subsystem if the target object changes.
2012-05-21 00:06   
I've uploaded a small modpack. The mission included crashes 80% of the time for me with the same error. I also included the capship torpedos because I haven't tested enough to confirm any bombs other than those torpedos and the Helios trigger the crash (even though it seems quite likely).
2012-05-21 03:04   
I did get an assertion to trigger, hopefully its the same one that you were getting.

 Assert: ship_obj->type == OBJ_SHIP
File: modelread.cpp
Line: 3915

ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_13d_INF_SSE2.exe! SCP_DumpStack + 354 bytes
fs2_open_3_6_13d_INF_SSE2.exe! WinAssert + 208 bytes
fs2_open_3_6_13d_INF_SSE2.exe! find_submodel_instance_point + 66 bytes
fs2_open_3_6_13d_INF_SSE2.exe! find_submodel_instance_world_point + 47 bytes
fs2_open_3_6_13d_INF_SSE2.exe! get_subsystem_pos + 162 bytes
fs2_open_3_6_13d_INF_SSE2.exe! get_subsystem_world_pos + 47 bytes
fs2_open_3_6_13d_INF_SSE2.exe! weapon_home + 1812 bytes
fs2_open_3_6_13d_INF_SSE2.exe! weapon_process_post + 1527 bytes
fs2_open_3_6_13d_INF_SSE2.exe! obj_move_all_post + 108 bytes
fs2_open_3_6_13d_INF_SSE2.exe! obj_move_all + 367 bytes
fs2_open_3_6_13d_INF_SSE2.exe! game_simulation_frame + 1116 bytes
fs2_open_3_6_13d_INF_SSE2.exe! game_frame + 468 bytes
fs2_open_3_6_13d_INF_SSE2.exe! game_do_frame + 242 bytes
fs2_open_3_6_13d_INF_SSE2.exe! game_do_state + 403 bytes
fs2_open_3_6_13d_INF_SSE2.exe! gameseq_process_events + 237 bytes
fs2_open_3_6_13d_INF_SSE2.exe! game_main + 782 bytes
fs2_open_3_6_13d_INF_SSE2.exe! WinMain + 330 bytes
fs2_open_3_6_13d_INF_SSE2.exe! __tmainCRTStartup + 322 bytes
fs2_open_3_6_13d_INF_SSE2.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes

What follows are my notes:
 Assertion caused by a Howell missile launched by an Osiris trying to get the position of turret05 of Helios launched by a ship that no longer exists. Neither capital ship has exploded. The Howell was jammed?

The Osiris that launched the Howell has the weapons subsystem of the Intrepid targeted. Has no last targeted subsystem. The Intrepid only has turret05a in its subsystem list.
2012-05-21 08:43   
That's it, yup.

The Howell was launched by an Osiris? Odd, I don't think any of the Osiris have Howell in their loadout...

Howells are launched by the Orion and Aratrums are launched by the Typhon.

Regardless, the mission has no jamming or events of any kind really. Just the capships and bombers showing up and fighting with arrival cues.
2012-05-21 09:19   
Hmm, so the plot thickens.
2012-06-08 06:21   
After debugging the assert I think I found the cause of the problem. Apparently the homing object of the weapon gets corrupted of the homing subsystem is destroyed. Somehow it gets set to another object which may or may not be a ship, if it isn't then the assert pops up but if it isn't then the weapon will home onto the turrets position on another ship.

This can be fixed by adding a homing object signature check before homing onto it to prevent bad things from happening.
With that change in place I haven't encountered any crashes and a weapon that looses the subsystem should continue on the current trajectory but I was unable to observe that.
2012-06-08 10:00   
My testing confirms the patch works.
2012-06-09 14:10   
Okay, the patch isn't what needs to be done. It adds a functionality which is redundant with what is already there, which is supposed to already work.

The actual cause of the problem, the code that "corrupts the homing object", isn't addressed in this patch. That code needs to be found in order for the problem to be truly solved.
2012-06-10 23:22   
Fix committed to trunk@8869.
2012-06-10 23:24   
Valathil's research revealed that the cause of the bug was a turret changing its target to another ship without also changing its targeted subsystem.
2012-07-01 21:21   
Fix committed to fs2_open_3_6_14@8953.

Issue History
2012-05-16 12:33MjnMixaelNew Issue
2012-05-19 23:38iss_mneurNote Added: 0013568
2012-05-19 23:38iss_mneurStatusnew => feedback
2012-05-20 08:12MjnMixaelNote Added: 0013574
2012-05-20 08:12MjnMixaelStatusfeedback => new
2012-05-20 16:25iss_mneurNote Added: 0013580
2012-05-20 16:25iss_mneurAssigned To => iss_mneur
2012-05-20 16:25iss_mneurStatusnew => feedback
2012-05-20 16:25iss_mneurTarget Version => 3.6.14
2012-05-20 16:29MjnMixaelNote Added: 0013581
2012-05-20 16:29MjnMixaelStatusfeedback => assigned
2012-05-20 16:39iss_mneurFile Added: mantis_2652.patch
2012-05-20 16:41iss_mneurNote Added: 0013582
2012-05-20 16:41iss_mneurStatusassigned => feedback
2012-05-21 00:05MjnMixaelFile Added: BombTestCrash.7z
2012-05-21 00:06MjnMixaelNote Added: 0013588
2012-05-21 00:06MjnMixaelStatusfeedback => assigned
2012-05-21 03:04iss_mneurNote Added: 0013591
2012-05-21 03:04iss_mneurStatusassigned => feedback
2012-05-21 08:43MjnMixaelNote Added: 0013597
2012-05-21 08:43MjnMixaelStatusfeedback => assigned
2012-05-21 09:19iss_mneurNote Added: 0013598
2012-06-08 06:21m_mNote Added: 0013637
2012-06-08 06:21m_mFile Added: mantis2652.patch
2012-06-08 10:00MjnMixaelNote Added: 0013638
2012-06-09 14:10Goober5000Note Added: 0013649
2012-06-10 22:39Goober5000Changeset attached => fs2open trunk r8866
2012-06-10 23:22Goober5000Changeset attached => fs2open trunk r8869
2012-06-10 23:22Goober5000Note Added: 0013654
2012-06-10 23:22Goober5000Statusassigned => resolved
2012-06-10 23:22Goober5000Resolutionopen => fixed
2012-06-10 23:23Goober5000Assigned Toiss_mneur => Valathil
2012-06-10 23:24Goober5000Note Added: 0013655
2012-07-01 21:21ZacamChangeset attached => fs2open fs2_open_3_6_14 r8952
2012-07-01 21:21ZacamChangeset attached => fs2open fs2_open_3_6_14 r8953
2012-07-01 21:21ZacamNote Added: 0013765