various memory leaks reported by valgrind

I'm hunting bugs, and decided to run a memgrind load of a map. The original file was rather long, with lot of very likely false positives, so I filtered it so that I think the logs are meaningful, and here is what I have:

really_def.txt

This file lists the blocks which are considered by valgrind as "definitely lost", on which I filtered out blocks with "???" and "below main" entries. Basically. I'm certain it can be reduced more, but I think this log should not be lot, thus I report this.

[slipher]

Did you make sure to patch this part?

void operator delete(void* p) NOEXCEPT
{
	if (!Sys::processTerminating) {
		free(p);
	}
}

To get rid of this, I've been planning to add a pedanticShutdown cvar, which will execute all atexit destruction stuff if enabled, or use quick_exit if disabled (default).

Actually, I think I eradicated it from my own unvanquished/whatever/ tree because it prevents me to run Asan.

That part of the code, do you really think it's useful?

[slipher]

It's useful to prevent process exit from doing a lot of useless compute. But quick_exit would be even better (no destructors at all rather than disabling just free).

I'm doubtful about the real usefulness, but why not. Still, the reports I have in those filtered logs are very likely, imo, worth investigations.
On a more general note, I think at least debug mode should be correct. I admit I didn't made this run in debug mode, but I doubt it would change anything. The correctness of debug mode would allow to find memleaks which bring no benefits in release mode, too.

In any case, it's true I didn't mentioned the context: that's just loading a map, and exiting the game. No bot, no player, one connected (me).

[VReaperV]

The audio thing seems to be fixed, and the GLSL shader pointers are put into std::unique_ptrs. The rest is presumably fixed when pedanticShutdown is set to on. Don't know what the sendmsg thing is about, it does not seem to be present in that code?