Infinite origin from vphysics! (entity tf_ammo_pack) PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110727000911_1.dmp Segmentation fault (core dumped) BFD: Warning: /home/srcds/srcds_new_test/orangebox/core is truncated: expected core file size >= 323883008, found: 1044480. Cannot access memory at address 0xb778b8e4 Cannot access memory at address 0xaf9eed20 /home/srcds/srcds_new_test/orangebox/debug.cmds:4: Error in sourced command file: Cannot access memory at address 0xb778b8e4 email debug.log to [email protected] Wed Jul 27 00:09:11 EDT 2011: Server restart in 10 seconds
Infinite origin from vphysics! (entity tf_ammo_pack) PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110727001149_1.dmp Segmentation fault (core dumped) BFD: Warning: /home/srcds/srcds_new_test/orangebox/core is truncated: expected core file size >= 311521280, found: 1077248. Cannot access memory at address 0xb770b8e4 Cannot access memory at address 0xaf96ed20 /home/srcds/srcds_new_test/orangebox/debug.cmds:4: Error in sourced command file: Cannot access memory at address 0xb770b8e4 email debug.log to [email protected] Wed Jul 27 00:11:49 EDT 2011: Server restart in 10 seconds bleh. On Tue, Jul 26, 2011 at 1:06 PM, Saint K. <[email protected]> wrote: > Fletch, > > Could you give us another progress update today? > > Cheers, > > Saint K. > ________________________________________ > From: [email protected] [ > [email protected]] On Behalf Of Fletcher Dunn [ > [email protected]] > Sent: 25 July 2011 22:15 > To: '[email protected]'; '[email protected]' > Subject: [hlds_linux] TF2 crashes > > 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_linux > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
