Crash @ 0x6341616 (Common.dll)
-
Need to know where it’s coming from to properly analyze, but this might work: [c]common.dll, 0E1620, C0->D2[/c]. That checks edx is 0, rather than eax (which is edx+4, so not likely to happen). Whether that’s sufficient remains to be seen…
-
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.
-
Possibly, but unless it compresses to under 50MB, I wouldn’t want to download it.
-
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
-
I just can confirm that. I also used to run own functions in different threads, not connected to the serverimpl namespace. This didnt worked and first after including them again resolved it
Further multithreading isnt really worth
