Crash @ 0x6341616 (Common.dll)
-
Hey,
we’ve got a crash @ 0x6341616 in Common.dll.
Does anyone has a clue what could cause this crash?
It’s part of the function at 0x6341610: protected: void __thiscall BaseWatcher::set_pointer(struct Watchable const *)
?set_pointer@BaseWatcher@@IAEXPBUWatchable@@@Zwhich seems to be called from a lot different positions.
The Disassembly at 0x6341616 is:
mov edx, [eax]edx = 0
eax = 4Any hint would be much appreciated.
Cheers,
Crazy -
-
To this day this is kind of a mistery I think [what the BaseWatcher does exactly):
-
We hadn’t a BaseWatcher crash till this morning.
So it’s actually working. But now I get the following crash:Unhandled exception at 0x06341616 (Common.dll) in flserver_16.07.2015_08.16.dmp-1.dmp: 0xC0000005: Access violation reading location 0x6F6C5F6B.
Same offset but this time with invalid data > 0 I guess:
EAX 0x6f6c5f6b
EBX 0x00000000
ECX 0x0c6df1b4
EDX 0x6f6c5f67
ESI 0x0ddd9c30
EDI 0x0c6df1b4
EBP 0x08926a50
EIP 0x06341616
ESP 0x038190f0In this case the return adress is: 0x062c28ee so it was called from 0x62C28E9 which is part of ScanList::add_in_range(class Vector const &,float,struct IObjDB *,unsigned int,struct Filter *);
Any idea how to fix the crash or how to find out what is causing it?
-
I don’t know how you can say it’s working, when it didn’t work…
As far as add_in_range is concerned, there’s an array of 256 watchables, so I thought it might be overflowing; but it does detect the limit and that crash is at the first one, anyway (EDI == ECX).
EDX contains ASCII for ‘g_lo’ (probably some engine or wing LOD), which suggests something else is overwriting the linked list (since EAX == EDX+4, it’s occurring after the first link), which means logging set_pointer wouldn’t help much (and I think it would log too much to be practical, anyway).
Don’t really know what to suggest.
-
I’d say the crashes aren’t that frequent as before after applying your patch (could have been luck :D).
I could try to add this function into Cannons CrashCatcher which would add a try/catch around every function call and hope for no side effects. I’d only need to patch over 200 adresses
-
You’d also have to catch unwatch, as that runs through the list, too. Even then, that only catches those two functions, not anything that actually uses the list directly. (set_pointer has 221 calls in common, 114 in freelancer and 15 in server.)
I did try removing the function altogether, but that crashed immediately on entering space; exiting early crashed on setting a target. It’s just used so often, I don’t even know where to begin.
-
Would a full memory dump during the crash help?
I only got a MiniDump of the MINIDUMP_TYPE MiniDumpNormal right now but I could extend it if that could help.
-
I fixed this crash by moving some calculations (including IObjectInspect stuff etc.) from an extra thread into the ServerImpl:Update method.
I think some function calls were overriding internal stuff (as adoxa already guesed).
Seems FLServer doesn’t like multihreading when you do any internal stuff.
Sorry for wasting your time
