Crash on System Change

[FriendlyFire]

So I’m wrestling with a particularly nasty bug which is extremely hard to track down. Our hyperspace system completely replaces regular jump gates and holes and relies on forced system switching to work.

In the majority of the cases, the entire thing works fine, but for certain players the game crashes when the system is switched. I’ve tried tracking it down, but couldn’t find anything conclusive.

The only thing I have is a bunch of dumps from after the actual problem which arise on every frame render. The error is:

Unhandled exception at 0x063456F8 (common.dll) in fwtow_06.01.2016_21.32.59-1.dmp: 0xC0000005: Access violation reading location 0x000000FC.

Tracing that down, I find a pretty short piece of code which seems to be involved in getting the ship’s center of mass. Since the only ship in hyperspace is the player’s, I’m assuming that that is the ship being handled. Looking at the particular line, edx is 0 and it’s set as ecx + 0x18.

I don’t know what ecx is though (it probably is the CObject?) and I have no information as to what’s at 0x18 since the dump doesn’t include that memory.

This sounds like information is being corrupted, but the fact it’s a null pointer instead of, say, an invalid floating point value, makes me puzzled.

Any ideas?

[DwnUndr]

Sounds like the beam bug. About 1 out of 8 times I beam someone and they F1, an undock causes them to crash out of the server. Totally random.

But if they beam and sit for a minute, then F1 and sit another minute, no crash. The server seems to check player positions and will auto-update given time.

[Huor]

Hm the exception offset seems to be:

 0 e 063456f8     0001 (0001)  0:**** Common!BaseWatcher::set_pointer+0x40e8

There are various stack traces when i set this breakpoint. But most are related to:

 #   Memory  ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
00           054ac6b8 06284585 054ac6f0 0d195500 00000001 Common!BaseWatcher::set_pointer+0x40e8
01        38 054ac6f0 06284555 00957118 0d2a7e88 00000001 Common!PhySys::GetCenterOfMass+0x15
02        28 054ac718 06284585 47015706 c42058fa 06284466 Common!PhySys::GetRadiusR+0x1e5
03           00000000 00000000 00000000 00000000 00000000 Common!PhySys::GetCenterOfMass+0x15

As usual the BaseWatcher::set_pointer
The set_pointer takes a Watchable struct pointer which could be everything. However when i try to get the symbol for that pointer then it is

054ac6f0 062844a5 Common!PhySys::GetRadiusR+0x135

As GetRadious takes an CObject pointer and a reference to a Vector (and a bool which doesnt play a role i guess) one of both seems to be null. As a reference cannot be null i assume its the CObject.

I am not sure whether this is of any useful information. I would assume its a timing issue, where for some players something is not yet constructed or destroyed or something like this.

[FriendlyFire]

Once the teleport has happened the game seems unable to recover. Since other teleports work fine, I have doubts it’s a timing issue.

Also, the code is definitely in GetCenterOfMass, not in any of those other functions. Look at the offsets, BaseWatcher::set_pointer not 0x40e8 bytes long. The call stack I get works its way back up through various updating functions, starting in CShip::update.

The only oddity is that if you go even before CShip::update, there are calls to readfile.dll. I’m not sure why file reads would happen there (maybe it’s loading the system and failing?) or why a file read would call the ship’s update function.