0.2.8.2_rc2: Release process and bugs

[Z-Man]

Unfortunately, a read from uninitialized/unowned memory has just popped up in rc1. Players with special names may be able to crash a server. No write operations are triggered by this, so it's not a security risk, but nevertheless, the bug needs to be fixed.
Other code changes have also been done, Nemo had to take care of Mac compilability and I had to mess a little more with the fake lag exploit, I think I found a way to at least stop an unmodded client from triggering it. There's an undocumented setting item for the case that modded clients crop up, but it will also have a negative effect on fair players.

While all the code changes should be perfectly safe, the Book of Rules says there has to be another RC. It'll be build it this weekend.

[Z-Man]

The builds are up on aabeta, SF to follow in some hours. Testing them, I noticed several oddities that must have been around for a while:

- The Windows uninstaller doesn't remove the desktop icons the installer created
- On SuSE and Debian Sarge, "/etc/init.d/armagetronad-dedicated stop" doesn't really stop the server
- On Debian Sarge, no program menu entries get created on the autopackage install.

Changes since the last rc:
- No longer chowning /var/log and /var/run
- Normal clients can no longer trick the server into thinking there was packet loss falsely
- A crashfix with short player names

Get them and have fun!

[Z-Man]

I just stumbled across a very old crash bug. When I tested the Windows build on Windows 98, the client crashed on the first run. I had hit some wild key combination I couldn't remember, and reproducing it with recording enabled didn't work. So I shrugged and went on.

Now, I've tested the client build on FreeBSD. Guess what? It crashed once on the first test run when I disconnected from a server, and with recording, I couldn't reproduce the crash.

Removing user.cfg and starting again with recording, I finally managed to reproduce it and have a nice recording. It seems the client tries to execute AI code. The bug only happens if you leave via the menu, shift-esc doesn't trigger it. An enemy AI needs to be in an emergency situation at the time you quit. So no wonder it wasn't reported before. The "first run" criterion isn't real, however, it can happen anytime.

The crash is a NULL pointer dereferencing crash and thus no security risk. The fix is easy and safe (check the pointer even in optimize mode) and can be put into 0.2.8.2 without another rc. A better fix that makes sure the situation doesn't happen at all will go into 0.2.8.3.

[Lucifer]

Is there a chance this is the same crash bug I've been having in cvs head (that I haven't bothered to mention before) from time to time? Only happens when I've been playing awhile...

But then, I don't play with AIs when it happens.

[Z-Man]

No, AIs on the server and you quitting via the "Disconnect" menu item are essential ingredients here.