Crash Offsets

@Huor: FindSphereCollisions could suggest a sur problem. Then again, looking at it, it looks like the warning is right, so I wouldn’t put too much credence on the trace. It’s a really strange error, since it already tests for ERROR and NULL, so eax appears legitimate, but is not. Furthermore, it looks like it’s telling you what is there, so it really is legitimate, so where’s the error coming from? Or is this just from a breakpoint, not a crash? Is there something I can test myself, or a remote connection?

I am not an server operator - just someone who might understand a bit of that coding stuff - but not at the level of Adoxa ;D

The stack back trace is made from a breakpoint and i have set the breakpoint to the offset where the server is causing crashes (engbase.dll + 0x0124bd) that we are hunting now for some weeks. I overstepped the breakpoint several times but the stack trace was looking always and nearly the same. So i assume that when it really crashes it must be one of these calling routines that may lead to the crash. And i tested it only client sided - the crash happens at the flserver - so it may be wrong what i wrote anyway.

We tried several stuff and it seems this crash offset is the only one remaining. We are using vanilla surs on the server for some weeks so normally that should not be related to it. Spheres are used for several stuff - so could it also have something to do with NPCs crashing into planet or something like this? As we did disable NPCs for some time the error wasnt there. So its really annoying to dont find the reason for this crash.

After tracing it myself, it appears to be related to cmp reading - it seems to return the parent object. It’s been called from GetRoot, Hierarchy::GetDepth and CEGun::ComputeTurretFrame. It appears there’s either something wrong with your cmp file, or with something that uses it. I’m afraid I can’t be more specific, without knowing where it’s actually crashing. If you look at [eax+0x0C], that should point you to which object is going wrong. For example, my current breakpoint has EAX = 0xA478770, [0xA47877C] is 0x9FF2550; [0x9FF2554] is 0x9FF25A1, a pointer to “equipment\models\weapons\li_laser_beam.cmp”. [eax+0x08] is similar, pointing to the particular .3db within the .cmp.

Here’s a plugin to log what’s happening with engbase at 0x124bd. Add it to dacomsrv.ini and you’ll get EXE\EngBase-0124BD-YYYY-MM-DD.hhmmss.txt (the time when the server was started). Since there’s a lot of data, I reset it every 100 calls, so there’s a slight possibility the crash will occur with no context. I also try another test for a bad address (thus preventing the crash); if it occurs, the file is renamed as *-bad_N_.txt (at least, I hope it is, didn’t actually test it).

Now we have sometimes 000c45a2 in content.dll - something wrong with npc, but what?

That’s a really strange address for a crash - cmp dword[ecx+34], 1 when there’s mov [ecx+2c], eax a few instructions earlier.

adoxa wrote:
That’s a really strange address for a crash - cmp dword[ecx+34], 1 when there’s mov [ecx+2c], eax a few instructions earlier.

i use http://the-starport.net/freelancer/forum/viewtopic.php?post_id=31645#forumpost31645 patch but think it is of wrong encounter parameters

Ah, that explains it. I did a better patch in an IM: 0C457F, 9981E2FF->7411EB05. Don’t forgot to undo the other one.

adoxa wrote:
Ah, that explains it. I did a better patch in an IM: 0C457F, 9981E2FF->7411EB05. Don’t forgot to undo the other one.

Undo #34 and apply this?

Yep. You have to restore the old one, otherwise the new one will have no effect.

adoxa wrote:
Ah, that explains it. I did a better patch in an IM: 0C457F, 9981E2FF->7411EB05. Don’t forgot to undo the other one.

Tried on vanilla content dll without patches - crash at 000c458f

That’s the original crash address. The new patch should have fixed it. If it didn’t, I guess the underlying problem remains. 0C458F, 8B0482->33C090 will definitely fix it, but removes the original randomness.

For testing something else, I removed the Docking Ring to Pittsburgh. On launch, content.dll crashed at c458f. In that case at least, the new patch worked.

Sill in test - works well

Tried to track it down but no joy, maybe someone here has an idea what:

content.dll, 1.0.1254.11, 00047bc4

ntdll.dll, 5.1.2600.5755, 000101b3

are?

ntdll.dll crashes - Not supported parameter or typing error, not supported/equipable archetype in players char file.

06F47BC4 - incorrect base position?

@Tiger: What’s the context? Breakpoint wasn’t triggered in a quick single player game.

@Helloween: You still haven’t gotten the hang of converting offset to address - 6EA0000 + 47BC4 = 6EE7BC4.

Those are the two offsets we get as the most frequent crash reasons. What makes me helpless is, that you can’t pinpoint a special player or NPC activity as the crashes happen randomly, some times the server runs crash free for three weeks and then crashes happen two or three times in a row. It happens with one player or ten players, in different systems and with players flying missions or simply trading.

I hope with a hint what is triggered I can get an idea where to look at.

Ah X) Dirty saying image base + offset

@Tiger: The content one appears to be related to NPCs and/or their chatter. What’s missing contains the from, to and cargo entries (amongst other stuff). Sorry, can’t be any more specific than that.