View Issue Details

IDProjectCategoryView StatusLast Update
0002847FSSCPgameplaypublic2013-08-09 12:47
ReporterArpit Assigned ToEchelon9  
PriorityurgentSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.6.18 
Target Version3.7.0 
Summary0002847: Assert: (team != -1) -- due to aicode issues tracking destroyed weapons
DescriptionWhen 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
TagsNo tags attached.

Activities

Goober5000

2013-04-20 18:42

administrator  

fs2_open.log (48,642 bytes)

Goober5000

2013-04-20 18:43

administrator   ~0014935

The proximate cause is a Shivan fighter targeting something that is OBJ_NONE. Still have to find out how that came about, though.

Echelon9

2013-04-21 01:17

developer   ~0014938

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.

Goober5000

2013-04-21 04:44

administrator   ~0014939

Interesting. Do you know when this bug started? Narrowing it down to a particular date range could help in debugging it.

Echelon9

2013-04-26 09:21

developer   ~0014958

Hrmm, have been unable to reproduce this with a recent Nightly build and FSPort 3.4

niffiwan

2013-04-29 09:19

developer   ~0014977

Last edited: 2013-04-29 09:45

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 :( )

Echelon9

2013-04-29 10:04

developer   ~0014978

Thanks for this, this is very useful

Goober5000

2013-04-30 00:45

administrator   ~0014985

Evangelist (sm2-09) in the FSPort does not have any asteroids or debris fields.

niffiwan

2013-04-30 01:35

developer   ~0014986

:( I'll have try to reproduce again, and this time remember to enable core files 1st

Echelon9

2013-06-15 01:56

developer   ~0015126

Have played through both missions a few times with trunk Debug builds, and have been unable to reproduce

Arpit

2013-06-19 06:39

reporter   ~0015132

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: )

Echelon9

2013-06-22 05:35

developer   ~0015134

Last edited: 2013-06-22 05:36

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()

Echelon9

2013-06-22 08:23

developer   ~0015135

Last edited: 2013-06-22 08:31

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.

Echelon9

2013-06-22 08:23

developer  

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) )

Echelon9

2013-06-22 08:24

developer  

Goober5000

2013-06-22 16:45

administrator   ~0015136

Well done. Progress! :)

FUBAR-BDHR

2013-06-26 00:55

developer   ~0015146

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.

Echelon9

2013-07-13 06:24

developer   ~0015183

The only references to priority in the mission file are:

+Escort priority: 0 <=== For the Eva and Raja

and a few

+Respawn priority: 0

FUBAR-BDHR

2013-07-13 07:24

developer   ~0015184

Not in the mission file in the tables. References to #Target Priorities groups defined in objecttyes.tbm/tbl.

Echelon9

2013-07-14 05:07

developer   ~0015185

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.

Echelon9

2013-07-14 05:08

developer   ~0015186

We should also consider the more widespread use of set_target_objnum(aip, -1) instead of aip->target_objnum = -1; short hand.

niffiwan

2013-07-16 00:00

developer   ~0015188

Do you have any more guidance/hints on how to reproduce the issue?

Echelon9

2013-07-16 13:05

developer   ~0015189

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.

Goober5000

2013-07-22 03:02

administrator   ~0015201

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.

Echelon9

2013-07-28 05:15

developer  

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) {
mantis-2847-fix-v2.patch (2,238 bytes)   

Echelon9

2013-07-28 05:16

developer   ~0015203

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.

niffiwan

2013-08-06 10:51

developer   ~0015211

Last edited: 2013-08-06 11:39

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.

niffiwan

2013-08-09 06:35

developer   ~0015212

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;
+ }

Echelon9

2013-08-09 12:47

developer   ~0015213

Thanks for those review comments. Will commit fix now.

Echelon9

2013-08-09 12:47

developer   ~0015214

Fix committed to trunk@9741.

Related Changesets

fs2open: trunk r9741

2013-08-09 09:57

Echelon9


Ported: N/A

Details Diff
Fix Mantis 2847: Assert: (team != -1) -- due to aicode issues tracking destroyed weapons Affected Issues
0002847
mod - /trunk/fs2_open/code/weapon/weapons.cpp Diff File

Issue History

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