That's most likely due to stack corruption. If it happened this week, keep going back revisions until you don't crash. Then figure out where in the code you MAY be dereferencing hanging pointers.
Kind regards, Saul Rennison On 28 January 2013 00:50, Cale Dunlap <cale.dun...@gmail.com> wrote: > I understand that crashes in the engine can and most often do result from > calls originating from the game dlls. However as I've said in the original > post, every active thread at the time of the crash contains no game code > anywhere in their respective callstacks. That's why I'm wondering if its > possible for someone at Valve to tell me the function in which the > referenced address resides. Since the PDB files for the engine aren't > public, the call stack information below the call in the stack at the > referenced address isn't reliable and therefore may still involve game > code. So if I knew the function in the engine DLL where the crash occurred > I could attempt to locate calls to that function from the game code and > possibly determine a cause of the crash and which code path led there. > > > On Sun, Jan 27, 2013 at 7:40 PM, Sammy <sam...@gmail.com> wrote: > >> Usually crashes in the engine are caused either by the map or game dlls, >> you could try with older versions and see if the crash still happens. Once >> you find where it started to happen it's easier to find the issue. >> >> 2013/1/27 Cale Dunlap <cale.dun...@gmail.com> >> >>> During our weekly play test for Firearms: Source today, we had a >>> unusually high number of crashes. 99% of the crashes were due to what >>> appears to be a NULL pointer exception or pure virtual function call >>> somewhere in engine.dll. >>> >>> If I provide a call address inside of engine.dll, would it be possible >>> for someone from Valve to tell me which engine function was being called? >>> Just wondering if maybe we're making a call to something that ended up >>> getting deprecated and ultimately removed from the code base yet the >>> declaration for the function still exists in the engine headers provided >>> with the SDK. >>> >>> The entire call stack for every running thread at the time of the crash >>> contains no game-side code, and this particular crash occurred in the main >>> thread. Without PDB's for the engine dll, anything below the offending >>> address in engine.dll may not be correct, meaning it may still be game-code >>> making the call, correct? Right now the calls prior to the address in which >>> it crashed are all calls to the OS Kernel's ReadFile function. I also saw >>> some crash dumps calling GetProcAddress right before the crash, which is >>> why I thought perhaps it was trying to make a pure virtual call (if the >>> symbol didn't exist). >>> >>> Any help would be very appreciated. The offending address is 0x100CC018, >>> assuming the base address of the engine.dll is 0x10000000. >>> >>> -Cale >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>> >>> >>> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
