>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 > > >
<<postbox-contact.jpg>>
<<postbox-contact.jpg>>
<<compose-unknown-contact.jpg>>
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
