GPF: TestReach

[Barbie]

Recently a user had this GPF while unloading the map "MH-FightOn.unr" on a server map travel:

history: TestReach <- UObject::GetFullName <- FReachSpec ...

GPF Screenshot

AFAIK he was the only user that got the GPF; I was also online at that time and for me unloading the map and server travel worked fine. (An additional info: that user was the only user voting for it and loaded it initially, I joined while the map was already running.)

Are there any information what can cause such kind of error? G00gle did not spit out useful results for this.

[sektor2111]

G00gle amazingly even if people think it knows everything, it doesn't know when Path-Net is broken by an ass or rammed by a server-tool for some purpose... inside such a Level. You'll learn to stay away from these "news", trust me doesn't worth wasting time patching - but happily editing it. If I'm not mistaking, I suspect that some paths were touched with U227 Editor and probably adding something which UT doesn't have - a la "Texture Byte Material" crashing clients at lightning such a surface with fake craps (materials for ON Screen images are only... pictures - nothing that can be touched like wood, stone, etc.).
I gotta admit I have to investigate what U227 does at pathing because it looks a bit different from UT's Editor and this... might be a problem... (Higor ???)

[Higor]

1 - That crash window is an incomplete log (about 10% of the whole thing).
2 - You're not looking at the crash window well enough to see a pattern and a very important word.
3 - Let me guess, the map vote is MapVoteUL?

[Barbie]

G00gle [...] doesn't know when Path-Net is broken

You can be sure that I did not search for this specific error message but for related info that can lead me to the reason what can cause such errors.

1 - That crash window is an incomplete log

Screenshot was taken by the user - I don't have further info.

2 - You're not looking at the crash window well enough to see a pattern and a very important word.

I'm a stupid Barbie, maybe you can help me.

3 - Let me guess, the map vote is MapVoteUL?

It is MapvoteLA13.

[Higor]

"Serialize" is the magic word.
What's going on here is a bad reference held by either a ScriptedTexture, Console or UWindow object during level switch.

[sektor2111]

I don't know what to say about MapVote types. I just modified one because I was playing default matches with monsters and mapvote was crapping my console due to Skaarj used in games. The rest of problems which I had with such stuff (reported by XC_Engine) was a ScriptedTexture/Screen ("imagine the possibilities" I read on a wall - sure - I have the possibility to delete MAP).

[Barbie]

"Serialize" is the magic word.
What's going on here is a bad reference held by either a ScriptedTexture, Console or UWindow object during level switch.

The way I understood Serialization is that the current state of a dynamic software system is written to a stream. This stream can be located in memory, on disk or somewhere else. Correct so far?
What makes me wonder is that the serialization happens while unloading the map - I can see no reason for this. For me unloading means: clear all lists, free all unneeded objects and memory, reset persisting variables to their initial state. Then a new set of whatever can be loaded.

Also I wonder that this happened to that player only (yesterday again) and not for others doing the server travel also at this moment.

[Higor]

Now you're getting at something.
Serialization in UT is a set generic functions used to signal variables in an object.

Serialization process in the level.

(level is a 'Object)
MyLevel ---> Actors
(LevelInfo is actor 0, a 'Object')
LevelInfo0 ---> XLevel (serialized before, skipped) > Level (self) > Location > Rotation > etc... > NavigationPointList
(InventorySpot335 happens to be first in list, keep serializing here)
InventorySpot335 ---> XLevel > Level > NextNavigationPoint

and so on and on

UObject::Serialize is a general purpose serialization function, the real trick comes in the serializating object a.k.a the FArchive.
The serializator object implements a '<<' operator used to put in the same line all the variables that are supposed to be serialized.
Sometimes, the << operator is subdefined for structs so structs get to be properly serialized.

Code: Select all

void UPalette::Serialize( FArchive& Ar )
{
	guard(UPalette::Serialize);
	Super::Serialize( Ar );

	Ar << Colors;
	if( Ar.Ver()<66 )
		for( INT i=0; i<Colors.Num(); i++ )
			Colors(i).A = 255;
	unguard;
}

The FArchive object implements the code used to serialize variables and objects.
When saving a map in Unreal Editor, all native c++ properties are serialized in a single block while all UnrealScript properties are serialized as in ID,Value
But during level switch, a process called Garbage Collection is spawned which is basically a FArchive dedicated to mark objects.
When spawned all objects are marked as 'unreachable' and then the serialize function simply goes over all properties finding references to other objects, if another object is hit, the 'unreachable' tag is removed.
When the whole process is finished, a final step goes through all the object list and deletes the objects still marked as 'unreachable'.

So what's the problem here?
Some objects can be forcefully deleted, instead of garbage collected. Also, some objects that are previously marked for deletion don't get properly dereferenced.
So when the game tries to access a variable pointing to a deleted object (which was not dereferenced), there's a segmentation fault.

This is a simple c++ way of triggering a similar segfault:

Code: Select all

ExampleObject->Target = new OtherObject;
delete ExampleObject->Target;
//ExampleObject->Target = NULL; >>>> deleted objects need to be dereferenced!
if ( ExampleObject->Target )
    ExampleObject->Target->Target = ExampleObject;

Back to unreal, how do we trigger this kind of crash?
We do so by referencing an actor belonging to the level we're playing on somewhere where we're not playing on.
You have 3 main locations here:
- Level
- Entry
- Elsewhere (packages, transient, etc)
UWindow objects belong to 'Transient', so referencing an actor from Level can cause a crash during the above process.
Console also belongs to 'Transient' and does reference actors in it's message display system... but console also has a notification that indicates level is about to be switched which allows it to clear the message list, something the UWindow system doesn't have!!!
ScriptedTexture needs to reference an actor as well, which would be the actor controlling what's drawn on said texture.

These are the most common reasons for a garbage collector crash, and the way to solve this is to be more responsible when coding windows or run a process before level switch that cleans up all references from Entry, Elsewhere to Level, like XC_Engine does (ha!).


===========================
There is one way to cause a segfault in unreal that even XC_Engine fails to fix:
- Create a window class.
- Spawn 300 actors.
- Reference any of these actors from the window.
- Destroy said actor.
- Then run an iterator to destroy all remaining actors.
- Wait for next tick.
- Try to access a property on the actor referenced by the window.
The game will crash because said actor is already gone from memory.

[sektor2111]

@Barbie
Sounds logic to remove all things at server-travel but me... thinking simple, I have some Coop problem. While I travel to next map probably I have weapons with me (objects which won't be destroyed - but no ammo that much). Eheh, UT itself is being gone if everything is removed, so we need whatever stuff to stay post-travel but managing these is The Deal in short terms.

SelfNote: It's really entertaining to see 456 InventorySpot types but... NONE Bot support

[Barbie]

Thanks for the answers, and yes, these possibly travelling objects had not come to my mind... Then of course currently existing objects have to be checked for travel on map switch, and if an already freed object is accessed, an error occur.

Because this happens only to that specific user (AFAIK), I assume that he has installed something within UT locally what causes this GPF. Could this be a correct guess?

[sektor2111]

Higor was speaking about cleaning things which doesn't happen in UWindow. Do player record something and trying to deal with that - saving whatever ? For me this crash looks hilarious and seems veery linked with some pathing stuff by looking at the whole picture, this map looks pretty strange anyway - it's playable in original MH because indeed HAS ITEMS a lot but RespawnTIme looks unknown as usual. I won't check game-log because I need peace right now - usually new content added doesn't fascinating me that much. TestReach is called by FindPathToward natives as I have deducted based on other map's crash with broken paths, if I well recall, but... something closer happened in path seeking and garbage purging during a match. That's why is not the best idea to have players spamming and to collect garbage in the same time - probably client is doing something wrong. By playing map Off-Line almost to end (getting tired of running through useless big rooms) bad things did not happen.

Else I'm gonna repeat myself not to drive others mad BUT XConsole still do HAS PROBLEMS, and this type of client crash is not unknown for me, but was a fascinating coincidence to see it often when I used XConsole. Because my client rarely and randomly was crashing in the same way here and there...