Crash Offsets

Anyone an idea about crash offset 0x00103141 in common.dll?

I tried looking for that offset but found no appropriate function. next to that is only public:

virtual enum Archetype::AClassType __thiscall Archetype::EqObj::get_class_type(void)const 0x063624b0 0x001024b0 2680 (0xa78) Common.dll

or this:

public: virtual enum HpAttachmentType __thiscall Archetype::Commodity::get_hp_type(void)const 0x063624b0 0x001024b0 2788 (0xae4) Common.dll

but they are not at 0x00103141 ;( So the crash seems to have happened +C91h from this.

Tracing it back through the debugger, one time it’s called is through PhySys::PhyCollisionStateManager::enable_collisions.

000603d6 common.dll?
And i see 000c458f in content.dll ;(

603d6 in common.dll is from IObjInspectImpl::is_targetable - looks like it’s targetted something it shouldn’t have.

Thx Adoxa! Are you using ollydbg?

I am, but in this case, searching a disassembly from a customised PeRdr was enough. Names are demangled using my own program (based on the API function), executed through the editor (TDE).

Ah, i am not familiar with programming but have checked #10 by ollydbg, it shows the same x))

Anyone know what 000c458f in content.dll is?

Yep - 8B!

=Alex= wrote:
Anyone know what 000c458f in content.dll is?

In my case it was patrol_path related(wrong encounter). so seems like encounters.

Actually if i see this offset i know that I’ll have to look through encounters once more, especially patrols(map and encounter-related files).
For example encounter is not listed in system .ini file or encounter.ini has some problems(not-existent shipclass etc.)

About 000c458f in content.dll

I have found on my local machine that if solar have wrong destructible archetype (NewArk for example is fuchu_core with hit_pts = 0 - different from client and server in my case) and player taken off from nearest base of this archetype (Manhattan)- server crashes instantly!

So the prob in an destructible archetype somewhere near player trying to take off.

P.S. It is about server-side on our Dod

Next researh:

also 000c458f error arises when nearby stations (within a zone? Vitaly?) are reputed not coinciding with reputation on the client-side.

But if to change reputation only one station on a server - all works

P.S. edx = 0 when debugger reach this offset (usually edx =1), may be there is workaround to prevent this register set to null?

engbase.dll, 1.11.0.173, 000124bd

I need to track this one down if possible, this is the only one that shows up on the server.

@Nightstalker: That function already tests if its input is 0 or -1, so you must have a major bug if it’s failing. Unfortunately, all I can tell you is that it’s called (at least) from GetRoot and IsDescendant.

@Helloween: EAX is the index; EDX is the base and the reason for the crash. It creates a list of items (not sure what, possibly ship types), but it expects at least one item; the crash occurs when there are no items. Here’s a patch that seems to work: content.dll, 0C456A, 07->2A. Of course, that just hides the problem, it doesn’t fix it.

Ah edx. thx.
I will try the fix at home

It only fails intermittently (No pattern that I can find, ranges from once every two weeks or can go a month or more sometimes), usually in intense NPC combat or PVP. GetRoot and IsDescendant, does this refer to sur files??

Adoxa you are master of Freelancer reveЯce engenееring, thx - all NY now under the Wilds control at my local machine

00010dea, common.dll?

-1<–—
06310DE1 mov edx, [eax+01h]
06310DE4 add edx, [ebx+00001450h]
06310DEA jmp 06310E31h
-1<–—
…

• Reference to USER32.MessageBoxA
  …
  06310E31 test esi, esi
  06310E33 jle 06310E4Fh

brrr if esi<=esi then jump?

@Nightstalker: I sympathize, such intermittent bugs are hard to track down. GetRoot accepts a CObject* and returns a CObject* (presumably a parent relationship). IsDescendant takes two longs (presumably hashes) and returns bool (the first object is a descendant of the second).

@Alex: Looks like you have a good without an equipment line.