Thanks for reporting. I think I know what's causing it and I introduced this bug because I was going off wrong assumptions. Hunk_FreeTempMemory can only free memory in a LIFO order as someone pointed out to me on IRC. I'll fix this when I get around to this.

ok, it should be fixed in r2081

Thanks, it works better (it doesn't crash anymore), however
there are two new issues so I'm reopening the bug:

1) It doesn't compile anymore with USE_VOIP=0

2) In single player mode, q3dm1 and q3dm2 (and probably other maps)
start with the bot and player somehow "merged" at the same respawn
location, as if they shared the same slot. The player even gets the
skin and the bot's name. r2076 also didn't have this issue.

Can you elaborate please how to reproduce this?

Sure, actually it happens on any map in any mode (SP or MP) with
bots, *except* on q3dm0 which makes me think it's related to the
Hunk_FreeTempMemory problem. All you need is to start a game from
the main menu.

It also doesn't happen if you start a map with the /map command
and add bots later.

When entering a game with bots, you start stuck into a wall at
some random location. Displaying scores from that point on show
you as another player (as Phobos on q3dm2 for instance). If you
try to move, you respawn elsewhere. Until you die the first time,
controls are mixed up (going forward strafes to the right etc).
The bot you replace is invisible. Its frags are displayed instead
of yours (you still lose the game if it wins).

Restarting a map (/map_restart) solves the issue.

After some extensive pla^Wtesting, I found that a few other maps
worked well or mostly:

q3dm0 - ok
q3tourney2 - ok
q3dm7 - ok
q3dm8 - depends on the first spawn point
q3dm9 - ok
q3dm10 - ok
q3tourney4 - depends on the first spawn point
q3dm13 - ok
q3dm15 - ok
q3dm17 - ok

The above maps work in r2080 every time except q3dm8 and q3tourney4,
which occasionally trigger Hunk_FreeTempMemory crashes. I never get
what I described in comment #5.

The same maps in r2081 also work well, again except for q3dm8 and
q3tourney4, which seem to act as in comment #5 depending on the
first spawn point.

On q3tourney4 in particular, where the first spawn point doesn't
change much (usually the center room), both r2080 and r2081 work
properly. When it's elsewhere, r2080 will usually crash while
r2081 acts as in comment #5.

I also reproduced this bug on a 32 bit Linux machine with Ubuntu,
although not as pronounced, most maps start with the player partly
fused to the ground, others with the exact same issues as above.

On this machine, some maps get loaded in a loop until interrupted
by an overflow message:

File "vm/cgame.qvm" found in "./baseq3/pak8.pk3"
VM file cgame compiled to 1320692 bytes of code
cgame loaded in 4593920 bytes on the hunk
stitched 0 LoD cracks
...loaded 1513 faces, 109 meshes, 22 trisurfs, 6 flares
CL_InitCGame:  1.18 seconds
4 msec to draw all images
Com_TouchMemory: 0 msec
********************
ERROR: Client command overflow
********************
----- Server Shutdown (Server crashed: Client command overflow) -----
==== ShutdownGame ====
AAS shutdown.
---------------------------
----- FS_Startup -----

When it happens, I can see bots faces displayed twice during
loading. This can be reproduced almost every time on all maps
in skirmish/FFA mode. On q3tourney4, the game actually loads
anarki twice (and it works properly with an extra bot).

Anyway, none of the above can be reproduced with r2076 which
seems to work perfectly.

Fixed r2089

Tested on my two computers, works great, thanks!