Thats the actual name of the update?

I was wondering if they were responsible for all the crashes, does it seem any more stable now?

And im begining to wonder if there are engi and pyro weapons in the other 2 rockets but valve are keeping them seperate since it would kill just about every server at once if they were released at the same time.

Good idea blocking these weapons for now

An even better idea would be to block that space weapon shit forever.

Back from the dead.
I've been playing on the SpA servers for a few years now. Good to see that all is still going so well.
Personally I was so happy to not have lazers all in my face this weekend.

From: hlds_linux-bounces@list.valvesoftware.com [hlds_linux-bounces@list.valvesoftware.com] On Behalf Of Fletcher Dunn [fletcherd@valvesoftware.com]
Sent: 25 July 2011 22:15
To: 'hlds_linux@list.valvesoftware.com'; 'hlds@list.valvesoftware.com'
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

All Linux Servers? If the server is hosted on Windows is it ok?

We are still working nonstop on the linux server crash. We found and fixed several other problems in the process. I don't believe any of them are the cause(s) of the crash(es) that have been going on since the 22nd.

- Fletch

Well we are blocking the weapons and still get crashes. So we can lift the block anyway.

I am totally against a general banning of certain weapons. If we go down this path we have to ban every weapon (including the stock ones) because anyone will have an argument against anything.

Still working nonstop on figuring out the crashes.

>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)

This is a great clue. Coincides perfectly with a gcc-specific problem I found in the mantreads code yesterday that could produce behaviour exactly like this. And it's also the most reasonable explanation as to why the crashes would be specific to particular weapons. I am hopeful.

We are going to have an optional update this morning for a Mac problem. It probably won't contain any server fixes.

I hope to have some good news for you soon.

- Fletch