#2, We disabled the 2 Dr. G weapons on our server and it hasnt crashed yet in awhile so far its working.
On Mon, Jul 25, 2011 at 1:15 PM, Fletcher Dunn <[email protected]>wrote: > Hey guys,**** > > ** ** > > A status update on the crashes. I have identified what I think are 3 > different problems.**** > > ** ** > > 1.) There's a bug in the replay system due to a flaw in libcurl using a > signal to handle DNS timeout. You can avoid this bug by using IP addresses > in your replay config, rather than DNS names. We will have a software > workaround in the next update or so that essentially does this same thing > automatically.**** > > ** ** > > 2.) There's a random memory scribble. It will manifest itself as "double > free" or "memory corruption" crash, depending on your OS. Some have > theorized than this is due to the Dr. G weapons. We cannot confirm this.* > *** > > ** ** > > 3.) There is a hang. From what information I have gathered, the last thing > in the log is something along the lines of "PreMinidumpCallback: updating > dump comment." In other words, it is hanging while attempting to report the > crash. This is particularly disastrous because it not only will it > interfere with auto-restart scripts (unless you have some sort of watchdog), > but it prevents the crash report from being generated and submitted, which > of course would help us fix it.**** > > ** ** > > A random memory scribble can cause all sorts of behaviour, so it's possible > that #2 is the real bug, and #3 just a side effect that sometimes attends > the main bug.**** > > ** ** > > We have not been able to reproduce any of these issues internally, and we > have had several playtests. (We, the actual developers, not a separate QA > department and not a group of interns, playtest the game every day, on > Windows and Linux servers.) However, our dedicated servers have experienced > the hang.**** > > ** ** > > It has been very difficult to track down and fix these crashes because we > seem to have several regressed all at once, and at least one of the problems > is interfering with the normal reporting mechanism. If anyone is able to > save a dump file (they usually go to /tmp/dumps), I would be great if you > could post them in some webspace and post a URL where they may be > downloaded. Or, if your console log shows that it was uploaded, please post > the report ID. The output will look something like this:**** > > ** ** > > PreMinidumpCallback: updating dump comment > Uploading dump (in-process) [proxy ''] > /tmp/dumps/crash_20110723191817_1.dmp > success = yes > response: CrashID=bp-445d6055-e9e7-420a-93b8-688a92110723**** > > ** ** > > Grabs of GDB stack traces, etc with raw addresses, are not totally useless, > but they are definitely much less useful. Even with symbols, a stack trace > does not have as much data as a dump has. So if we could get some actual > dumps, that would be really great.**** > > ** ** > > These crashes continue to be our top priority.**** > > ** ** > > - Fletch**** > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
