View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002847 | FSSCP | gameplay | public | 2013-04-20 15:38 | 2013-08-09 12:47 |
Reporter | Arpit | Assigned To | Echelon9 | ||
Priority | urgent | Severity | crash | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 3.6.18 | ||||
Target Version | 3.7.0 | ||||
Summary | 0002847: Assert: (team != -1) -- due to aicode issues tracking destroyed weapons | ||||
Description | When I run the mission(Evangelist) in Freespace Port the mission crashes within some 25-30 seconds and the message 'Freespace Open has stopped working' appears. I have not comfirmed yet but it is sometimes possible to play the mission by turning back immediately and not looking at hostiles until wingmen clear up some hostiles. On running in debug version, I get the following error: Assert: team != -1 File: object.cpp Line: 1864 fs2_open_3_6_18_DEBUG.exe! SCP_DumpStack + 344 bytes fs2_open_3_6_18_DEBUG.exe! WinAssert + 194 bytes fs2_open_3_6_18_DEBUG.exe! obj_team + 450 bytes fs2_open_3_6_18_DEBUG.exe! num_ships_attacking + 57 bytes fs2_open_3_6_18_DEBUG.exe! guard_object_was_hit + 837 bytes fs2_open_3_6_18_DEBUG.exe! maybe_update_guard_object + 189 bytes fs2_open_3_6_18_DEBUG.exe! ai_ship_hit + 1461 bytes fs2_open_3_6_18_DEBUG.exe! ship_apply_local_damage + 348 bytes fs2_open_3_6_18_DEBUG.exe! ship_weapon_do_hit_stuff + 400 bytes fs2_open_3_6_18_DEBUG.exe! ship_weapon_check_collision + 1877 bytes fs2_open_3_6_18_DEBUG.exe! collide_ship_weapon + 351 bytes fs2_open_3_6_18_DEBUG.exe! obj_collide_pair + 2327 bytes fs2_open_3_6_18_DEBUG.exe! obj_find_overlap_colliders + 417 bytes fs2_open_3_6_18_DEBUG.exe! obj_sort_and_collide + 288 bytes fs2_open_3_6_18_DEBUG.exe! obj_move_all + 1076 bytes fs2_open_3_6_18_DEBUG.exe! game_simulation_frame + 1115 bytes fs2_open_3_6_18_DEBUG.exe! game_frame + 471 bytes fs2_open_3_6_18_DEBUG.exe! game_do_frame + 239 bytes fs2_open_3_6_18_DEBUG.exe! game_do_state + 379 bytes fs2_open_3_6_18_DEBUG.exe! gameseq_process_events + 237 bytes fs2_open_3_6_18_DEBUG.exe! game_main + 782 bytes fs2_open_3_6_18_DEBUG.exe! WinMain + 330 bytes fs2_open_3_6_18_DEBUG.exe! __tmainCRTStartup + 358 bytes fs2_open_3_6_18_DEBUG.exe! WinMainCRTStartup + 15 bytes kernel32.dll! BaseThreadInitThunk + 18 bytes ntdll.dll! RtlInitializeExceptionChain + 99 bytes ntdll.dll! RtlInitializeExceptionChain + 54 bytes | ||||
Tags | No tags attached. | ||||
|
|
|
The proximate cause is a Shivan fighter targeting something that is OBJ_NONE. Still have to find out how that came about, though. |
|
This is good that we've got a clear reproduction of this bug, which has been occurring sporadically in M6 of Diaspora for some users. |
|
Interesting. Do you know when this bug started? Narrowing it down to a particular date range could help in debugging it. |
|
Hrmm, have been unable to reproduce this with a recent Nightly build and FSPort 3.4 |
|
Just had this occur in the 2nd mission of ST:R, gdb backtrace follows: #0 0x00007ffff58ca425 in __GI_raise (sig=<optimised out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 0000001 0x00007ffff58cdb8b in __GI_abort () at abort.c:91 0000002 0x00000000008768b7 in WinAssert (text=0x949d12 "team != -1", filename=0x94953b "object/object.cpp", line=1864) at windows_stub/stubs.cpp:109 0000003 0x000000000070414d in obj_team (objp=0x12a5760) at object/object.cpp:1864 0000004 0x000000000043656a in num_ships_attacking (target_objnum=1824) at ai/aicode.cpp:9154 0000005 0x0000000000436e05 in guard_object_was_hit (guard_objp=0x11b6440, hitter_objp=0x129d180) at ai/aicode.cpp:9367 0000006 0x0000000000436fc8 in maybe_update_guard_object (hit_objp=0x11b3360, hitter_objp=0x129d180) at ai/aicode.cpp:9405 0000007 0x000000000044647a in ai_ship_hit (objp_ship=0x11b3360, hit_objp=0x12b4de0, hitpos=0x7fffffffd95c, shield_quadrant=-1, hit_normal=0x0) at ai/aicode.cpp:14730 0000008 0x000000000080db35 in ship_apply_local_damage (ship_obj=0x11b3360, other_obj=0x12b4de0, hitpos=0x7fffffffd95c, damage=8, quadrant=-1, create_spark=true, submodel_num=13, hit_normal=0x0) at ship/shiphit. cpp:2391 0000009 0x0000000000894cbf in ship_weapon_do_hit_stuff (ship_obj=0x11b3360, weapon_obj=0x12b4de0, world_hitpos=0x7fffffffd95c, hitpos=0x7fffffffd950, quadrant_num=-1, submodel_num=13, hit_dir=...) at object/col lideshipweapon.cpp:94 0000010 0x00000000008955e0 in ship_weapon_check_collision (ship_objp=0x11b3360, weapon_objp=0x12b4de0, time_limit=0.257995605, next_hit=0x7fffffffdcb0) at object/collideshipweapon.cpp:292 #11 0x0000000000895d4e in check_inside_radius_for_big_ships (ship=0x11b3360, weapon=0x12b4de0, pair=0x7fffffffdd40) at object/collideshipweapon.cpp:442 0000012 0x00000000008959da in collide_ship_weapon (pair=0x7fffffffdd40) at object/collideshipweapon.cpp:360 0000013 0x00000000006fcf1c in obj_collide_pair (A=0x11b3360, B=0x12b4de0) at object/objcollide.cpp:1626 0000014 0x00000000006fbc6d in obj_find_overlap_colliders (overlap_list_out=0x7fffffffde80, list=0x7fffffffdea0, axis=2, collide=true) at object/objcollide.cpp:1246 0000015 0x00000000006fba49 in obj_sort_and_collide () at object/objcollide.cpp:1211 0000016 0x0000000000703874 in obj_move_all (frametime=0.016998291) at object/object.cpp:1515 0000017 0x00000000004126bd in game_simulation_frame () at freespace2/freespace.cpp:3987 0000018 0x000000000041317d in game_frame (paused=false) at freespace2/freespace.cpp:4380 0000019 0x0000000000413dc5 in game_do_frame () at freespace2/freespace.cpp:4791 0000020 0x000000000041609d in game_do_state (state=2) at freespace2/freespace.cpp:6467 0000021 0x00000000004bc9d0 in gameseq_process_events () at gamesequence/gamesequence.cpp:405 0000022 0x0000000000416ef7 in game_main (cmdline=0x24ea880 "") at freespace2/freespace.cpp:7034 0000023 0x00000000004170f7 in main (argc=1, argv=0x7fffffffe2b8) at freespace2/freespace.cpp:7168 One bit of interesting info, the object causing the assertion was OBJ_NONE, its parent was OBJ_ASTEROID, does the problem only occur in missions with asteroids? (gdb) print objp->type $8 = 0 '\000' (gdb) print objp->parent_type $9 = 13 '\r' (and I wish I'd got a core file so I could analyse this more later :( ) |
|
Thanks for this, this is very useful |
|
Evangelist (sm2-09) in the FSPort does not have any asteroids or debris fields. |
|
:( I'll have try to reproduce again, and this time remember to enable core files 1st |
|
Have played through both missions a few times with trunk Debug builds, and have been unable to reproduce |
|
Oh my error is still being looked at. :) Just would like to ask whether there are bombers in mission 6 of Diaspora. (Reason why I am asking this? Well, I was playing last mission of ST:R and after destroying the Hades and completing the mission I set out to destroy the remaining cargos with my Harbingers for fun. When I launched my bomb at one of the cargo my Banshee turret was trying to destroy my own bomb! The cargo units were at more than 1000m distance so my turret was clearly shooting at my Harbingers.(I saw its vector towards the lead indicator of the bomb) So perhaps the object causing assertion is a bomb. :not sure: ) |
|
I've been able to reproduce the error a few sporadic times with the Evangelist mission, there at present is not clear pattern to reproduce. What I know: - The object causing the assertion has type OBJ_NONE - OBJ_NONE is set in only three places * obj_init() for each object at startup * obj_free(), and * obj_delete() - If it's happening after obj_free() or obj_delete() is called, there is an internal issue in the engine keeping references to removed objects. - I've setup some extra logging locally to track through if obj_free() or obj_delete() have been called on our particular object that triggers the Assert() |
|
This bug is caused by a reference to a previously obj_delete()'ed and obj_free()'ed weapon (looks to be a Stiletto) subsequently getting passed into: // aicode.cpp:9367 // aip->target_objnum is the index into Objects[] of the Stiletto weapon num_attacking_cur = num_ships_attacking(aip->target_objnum); That is, following obj_delete() and obj_free() the Weapon has been cleared and the type set to the dummy OBJ_NONE. Now we need to work out why the Shivan fighter, in its ai_info struct, still thinks it is a valid target. The attached debugging patch was used to produce the attached fs2open.log. Notice that Objects[14] has been previously deleted and freed. |
|
debugging_for_mantis_2847.patch (1,496 bytes)
Index: code/object/object.cpp =================================================================== --- code/object/object.cpp (revision 9697) +++ code/object/object.cpp (working copy) @@ -393,6 +393,8 @@ if (!Object_inited) obj_init(); Assert( objnum >= 0 ); // Trying to free bogus object!!! + + mprintf(("obj_free() called on Objects[%i]\n", objnum)); // get object pointer objp = &Objects[objnum]; @@ -520,6 +522,11 @@ return; }; + mprintf(("obj_delete() called on Objects[%i] of type %s\n", objnum, Object_type_names[objp->type])); + if (objp->type == OBJ_WEAPON) { + mprintf((" Objects[%i]: Weapon name = %s\n", objnum, Weapon_info[Weapons[objp->instance].weapon_info_index].name)); + } + // Remove all object pairs if ( Cmdline_old_collision_sys ) { obj_remove_pairs( objp ); @@ -598,7 +605,7 @@ // if a persistant sound has been created, delete it obj_snd_delete_type(OBJ_INDEX(objp)); - + objp->type = OBJ_NONE; //unused! objp->signature = 0; Index: code/ai/aicode.cpp =================================================================== --- code/ai/aicode.cpp (revision 9697) +++ code/ai/aicode.cpp (working copy) @@ -9151,6 +9151,7 @@ ai_info *attacking_aip; ship_obj *so; int count = 0; + mprintf(("Target object is Objects[%i]\n", target_objnum)); int target_team = obj_team(&Objects[target_objnum]); for ( so = GET_FIRST(&Ship_obj_list); so != END_OF_LIST(&Ship_obj_list); so = GET_NEXT(so) ) |
|
|
|
Well done. Progress! :) |
|
Are there target priority groups involved? I remember a similar issue caused during Diaspora development due to a typo in a target priority group name. |
|
The only references to priority in the mission file are: +Escort priority: 0 <=== For the Eva and Raja and a few +Respawn priority: 0 |
|
Not in the mission file in the tables. References to #Target Priorities groups defined in objecttyes.tbm/tbl. |
|
I believe I've nailed this bug, by duplicating the ship code which cleans up AI targeting structures once a target ship is destroyed. This clean-up code was not present in the weapon destruction code. The resolution appears complete from my testing, and behaves in a performant manner. Please test extensively. |
|
We should also consider the more widespread use of set_target_objnum(aip, -1) instead of aip->target_objnum = -1; short hand. |
|
Do you have any more guidance/hints on how to reproduce the issue? |
|
Not really. I was able to intermittently cause it by missile spamming Stilettos in the early part of Evangelist FSPort mission. If the Assert() hasn't triggered within the first 2 minutes, restart the mission as it is very unlikely to do so after that point. |
|
Careful with that patch. I assume you copied it from the ship cleanup code, because it still refers to a ship in at least one place where it should refer to a weapon: + if ((aip->guard_wingnum != -1) && (aip->guard_wingnum == Ai_info[Ships[Objects[objnum].instance].ai_index].wing)) { Pretty sure that objnum is a weapon in this case. |
|
mantis-2847-fix-v2.patch (2,238 bytes)
Index: code/weapon/weapons.cpp =================================================================== --- code/weapon/weapons.cpp (revision 9735) +++ code/weapon/weapons.cpp (working copy) @@ -5865,8 +5865,13 @@ int weapon_type = Weapons[num].weapon_info_index; int expl_ani_handle; weapon_info *wip; - weapon *wp; + weapon *wp; bool hit_target = false; + + object *other_objp; + ship_obj *so; + ship *shipp; + int objnum; Assert((weapon_type >= 0) && (weapon_type < MAX_WEAPONS)); if((weapon_type < 0) || (weapon_type >= MAX_WEAPONS)){ @@ -5874,6 +5879,7 @@ } wp = &Weapons[weapon_obj->instance]; wip = &Weapon_info[weapon_type]; + objnum = wp->objnum; // check if the weapon actually hit the intended target if (wp->homing_object != NULL) @@ -5882,7 +5888,6 @@ //This is an expensive check bool armed_weapon = weapon_armed(&Weapons[num], hit_target); - // int np_index; // if this is the player ship, and is a laser hit, skip it. wait for player "pain" to take care of it if ((other_obj != Player_obj) || (wip->subtype != WP_LASER) || !MULTIPLAYER_CLIENT) { @@ -5962,6 +5967,37 @@ } } } + + // For all objects that had this weapon as a target, wipe it out, forcing find of a new enemy + for ( so = GET_FIRST(&Ship_obj_list); so != END_OF_LIST(&Ship_obj_list); so = GET_NEXT(so) ) { + other_objp = &Objects[so->objnum]; + Assert(other_objp->instance != -1); + + shipp = &Ships[other_objp->instance]; + Assert(shipp->ai_index != -1); + + ai_info *aip = &Ai_info[shipp->ai_index]; + + if (aip->target_objnum == objnum) { + set_target_objnum(aip, -1); + // If this ship had a dynamic goal of chasing the dead ship, clear the dynamic goal. + if (aip->resume_goal_time != -1) + aip->active_goal = AI_GOAL_NONE; + } + + if (aip->goal_objnum == objnum) { + aip->goal_objnum = -1; + aip->goal_signature = -1; + } + + if (aip->guard_objnum == objnum) { + aip->guard_objnum = -1; + aip->guard_signature = -1; + } + + if (aip->hitter_objnum == objnum) + aip->hitter_objnum = -1; + } // single player and multiplayer masters evaluate the scoring and kill stuff if (!MULTIPLAYER_CLIENT) { |
|
Good pickup Goober. In fact I think that whole if() block there is redundant, as a Weapon cannot be part of a wing for the purposes of guarding that wing. Have reissued the patch and attached. |
|
Without the patch, have reproduced in 5 of 13 attempts playing Evangelist until all Stilettos (25-45) have impacted the Eva. With the patch, unable to reproduce in 20+ attempts of the same mission. |
|
I had a thought, this issue has occurred in missions without bomb-flag-weapons, e.g. 2nd mission of ST:R (see http://scp.indiegames.us/mantis/view.php?id=2847#c14977). Should a similar clearing of AI goals occur when an asteroid (or debris) is removed? I had a quick look but so far haven't been able to find where asteroid destruction is handled. My only comments (nitpicks really) about the current patch are that it has some trailing whitespace that could be removed, this comment: // If this ship had a dynamic goal of chasing the dead ship, clear the dynamic goal. should probably read: // If this ship had a dynamic goal of chasing this weapon, clear the dynamic goal. And lastly I think its safer to have braces around all if statement blocks, even the single line-ers. i.e. + if (aip->hitter_objnum == objnum) { + aip->hitter_objnum = -1; + } |
|
Thanks for those review comments. Will commit fix now. |
|
Fix committed to trunk@9741. |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-04-20 15:38 | Arpit | New Issue | |
2013-04-20 18:42 | Goober5000 | File Added: fs2_open.log | |
2013-04-20 18:43 | Goober5000 | Note Added: 0014935 | |
2013-04-21 01:17 | Echelon9 | Note Added: 0014938 | |
2013-04-21 01:17 | Echelon9 | Assigned To | => Echelon9 |
2013-04-21 01:17 | Echelon9 | Status | new => confirmed |
2013-04-21 04:44 | Goober5000 | Note Added: 0014939 | |
2013-04-26 09:21 | Echelon9 | Note Added: 0014958 | |
2013-04-26 09:22 | Echelon9 | Status | confirmed => feedback |
2013-04-29 09:19 | niffiwan | Note Added: 0014977 | |
2013-04-29 09:45 | niffiwan | Note Edited: 0014977 | |
2013-04-29 10:04 | Echelon9 | Note Added: 0014978 | |
2013-04-30 00:45 | Goober5000 | Note Added: 0014985 | |
2013-04-30 01:35 | niffiwan | Note Added: 0014986 | |
2013-06-15 01:56 | Echelon9 | Note Added: 0015126 | |
2013-06-19 06:39 | Arpit | Note Added: 0015132 | |
2013-06-19 06:39 | Arpit | Status | feedback => assigned |
2013-06-22 05:35 | Echelon9 | Note Added: 0015134 | |
2013-06-22 05:36 | Echelon9 | Note Edited: 0015134 | |
2013-06-22 08:23 | Echelon9 | Note Added: 0015135 | |
2013-06-22 08:23 | Echelon9 | File Added: debugging_for_mantis_2847.patch | |
2013-06-22 08:24 | Echelon9 | File Added: fs2_open_with_debugging_patch.log | |
2013-06-22 08:25 | Echelon9 | Note Edited: 0015135 | |
2013-06-22 08:31 | Echelon9 | Note Edited: 0015135 | |
2013-06-22 16:45 | Goober5000 | Note Added: 0015136 | |
2013-06-23 16:54 | Echelon9 | Priority | high => urgent |
2013-06-23 16:54 | Echelon9 | OS | Windows 7 Home Basic => |
2013-06-23 16:54 | Echelon9 | OS Version | Service pack 1 => |
2013-06-23 16:54 | Echelon9 | Platform | Windows => |
2013-06-23 16:54 | Echelon9 | Target Version | => 3.7.0 |
2013-06-23 16:54 | Echelon9 | Summary | Crash in mission Evangelist in Freespace Port within some seconds after mission entry => Assert: (team != -1) -- due to aicode issues tracking destroyed weapons |
2013-06-26 00:55 | FUBAR-BDHR | Note Added: 0015146 | |
2013-07-13 06:24 | Echelon9 | Note Added: 0015183 | |
2013-07-13 07:24 | FUBAR-BDHR | Note Added: 0015184 | |
2013-07-14 05:05 | Echelon9 | File Added: mantis-2847-fix.patch | |
2013-07-14 05:07 | Echelon9 | Note Added: 0015185 | |
2013-07-14 05:07 | Echelon9 | Assigned To | Echelon9 => The_E |
2013-07-14 05:07 | Echelon9 | Status | assigned => code review |
2013-07-14 05:08 | Echelon9 | Note Added: 0015186 | |
2013-07-16 00:00 | niffiwan | Note Added: 0015188 | |
2013-07-16 13:05 | Echelon9 | Note Added: 0015189 | |
2013-07-22 03:02 | Goober5000 | Note Added: 0015201 | |
2013-07-28 05:15 | Echelon9 | File Deleted: mantis-2847-fix.patch | |
2013-07-28 05:15 | Echelon9 | File Added: mantis-2847-fix-v2.patch | |
2013-07-28 05:16 | Echelon9 | Note Added: 0015203 | |
2013-08-06 10:51 | niffiwan | Note Added: 0015211 | |
2013-08-06 11:39 | niffiwan | Note Edited: 0015211 | |
2013-08-09 06:35 | niffiwan | Note Added: 0015212 | |
2013-08-09 12:44 | Echelon9 | Assigned To | The_E => Echelon9 |
2013-08-09 12:44 | Echelon9 | Status | code review => assigned |
2013-08-09 12:47 | Echelon9 | Note Added: 0015213 | |
2013-08-09 12:47 | Echelon9 | Changeset attached | => fs2open trunk r9741 |
2013-08-09 12:47 | Echelon9 | Note Added: 0015214 | |
2013-08-09 12:47 | Echelon9 | Status | assigned => resolved |
2013-08-09 12:47 | Echelon9 | Resolution | open => fixed |