Since it's thread related I suggest you attach a debugger and replicate the crash, there's a chance you'll find it pointing somewhere in your code.
2013/1/28 Cale Dunlap <cale.dun...@gmail.com> > From what I could tell, the stack wasn't corrupt, I did see valid calls to > the OS kernel... or at least what I would expect to be valid calls to the > kernel at the time of the crash (waiting for mutex on some threads, and > obviously the exception on the main thread where the crash occurred). None > of the addresses appeared random and were all within valid memory bounds of > modules that were active at the time of the crash. > > Anyway, I went back through the revisions between last week and this week > and only one thing changed... the removal of several screenspace effects, > that is all. Very little changed between last week and this week's test. > Regardless, we're going to try playing last week's build next weekend to > see what happens. The weekend play tests are the only time we get the > player counts up to the level at which we need them in order to see the > crashes; as it seems load-dependent. Otherwise we do small regression tests > during the week if any larger and/or sensitive changes have taken place, > but lately those haven't been happening due to our upcoming release. > > I agree that it would be nice to have stripped PDB's, if nothing else to > size out the call stack information so its at least reliable. However, I > understand the business reason to not have them available so I can't say I > blame Valve for not making them public, it isn't in their best interest to > do so from their perspective. It is for that reason that I decided to take > a long-shot and ask for help with it. I figured if nothing else maybe > someone in the community could offer up some insight. > > > On Mon, Jan 28, 2013 at 11:30 AM, Nicholas Hastings < > psycho...@alliedmods.net> wrote: > >> Stripped PDBs would give an idea of where crashes happen without having >> nearly as much information. >> >> http://msdn.microsoft.com/en-us/library/y87kw2fd(v=vs.110).aspx >> >> Sammy <sam...@gmail.com> >> Monday, January 28, 2013 11:26 AM >> Unfortunately it also exposes the source code of the engine in a human >> readable way, line by line except for comments, with the right tools. Which >> is why, I believe, they don't. >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> Neico <ad...@neic0.de> >> Monday, January 28, 2013 4:26 AM >> It really would help if Valve would provide an Symbol Server like >> SourceMod and Microsoft do, it makes the whole debugging process way >> easier... >> >> - Neico >> >> On 28.01.2013 07:39:56 GMT+0100, Sammy <sam...@gmail.com><sam...@gmail.com> >> wrote: >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> Sammy <sam...@gmail.com> >> Monday, January 28, 2013 1:39 AM >> I support Saul. Often when it happens with me it's some stupid little >> thing I forgot or did wrong in the code. You don't have to manually go rev >> by rev, try to remember exactly when it started to happen, the sooner the >> better, if not try to identify a rev you're sure would not be the issue, >> like before you've started working on the current feature or when you >> lastly released a patch, then keep decreasing the possibilities until the >> possibilities are minimal. >> I remember cases where a single line caused crashes with no call stack or >> random addresses in the engine. >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> Saul Rennison <saul.renni...@gmail.com> >> Sunday, January 27, 2013 8:02 PM >> 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 >> >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> Cale Dunlap <cale.dun...@gmail.com> >> Sunday, January 27, 2013 7:50 PM >> 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. >> >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> >> -- >> Nicholas Hastings >> AlliedMods.net <http://www.alliedmods.net> >> >> >> _______________________________________________ >> 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 > > >
<<compose-unknown-contact.jpg>>
<<postbox-contact.jpg>>
<<postbox-contact.jpg>>
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
