The previous commit's message claims the race can lead to duplicated
output, use after free, then double-free. That's correct only up to
the use after free. There is no double-free.
Heap corruption (double-free?) has been observed in Changeling,
though. Player logged in (still in sanctuary), map #, crashed within
removecc()'s free(io->data). Partial backtrace:
raise () from /lib64/libc.so.6
abort () from /lib64/libc.so.6
__libc_message () from /lib64/libc.so.6
malloc_printerr () from /lib64/libc.so.6
removecc (ioq=0x251fd10, cc=468) at ../src/lib/gen/ioqueue.c:350
ioq_dequeue (ioq=0x251fd10, cc=468) at ../src/lib/gen/ioqueue.c:135
io_output (iop=0x251fc90, wait=1) at ../src/lib/empthread/io.c:231
recvclient (cmd=0x258d8e0 "", size=1024) at ../src/lib/player/recvclient.c:82
getcommand (combufp=0x2557068 "map #1") at ../src/lib/player/empdis.c:84
I haven't been able to reproduce.
To hopefully catch ioqueue going south earlier, make ioq_dequeue()
oops when it can't dequeue as many bytes as requested.
Move call of ioq_makeiov() to its use, because calling it before
empth_select() is racy, as follows.
Player thread flushes output by calling io_output(player->iop, 1).
io_output() sets up iov[] to point to queued output. empth_select()
blocks on output.
Another thread sends a C_FLASH or C_INFORM message to this player.
This calls io_output(p->iop, 0). The output file descriptor has
become writable since the player thread blocked on it, so some output
gets written and dequeued.
The player thread resumes, writes out iov[] and dequeues. Any output
already written by the other thread gets duplicated. If the other
thread's dequeue operation freed struct io buffers, there's use after
free followed by double-free.
If defenders get to shoot before bombs are dropped, they surely get to
shoot before time-consuming missions like sweep and sonar.
Sweep and sonar used to happen after air defense, but before flak and
interception. Air defense existed from Chainsaw 3 to v4.3.19.
plane_sona() prints an empty line to make sonar contacts stand out.
Move it so the contact is visually "attached" to the right sector,
like this:
flying over sea at 15,-3
Sonar contact in 15,-3
sub #3 13,-3
flying over sea at 13,-3
Before:
flying over sea at 15,-3
Sonar contact in 15,-3
sb submarine (#3) 13,-3
flying over sea at 13,-3
struct trdstr members trd_x, trd_y are used only for teleporting
trades. For others, trad() wrote garbage coordinates to the trade
file. They weren't used except by xdump. Fortunately, even there
they're visible only to deities.
Write invalid coordinates instead. Do that in set() as well, so that
coordinates are valid only when we have a teleport destination.
Spotted by the Clang Static Analyzer.
It showed unit coordinates in unit's coordinate system instead of the
actor's. Fortunately, they're the same, since it is reachable only
for non-zero actor, only shp_nav_one_sector(), lnd_mar_one_sector()
and sail_nav_fleet() pass that, and even deities can't navigate
foreign ships or march foreign land units.
Limited since Chainsaw 2 so that the radar map fits into a world map
without clipping, i.e. its diameter neither exceeds WORLD_X / 2 nor
WORLD_Y. Maybe range exceeding that triggered bugs then. It doesn't
now, and it makes no sense.
The limit never applied to automatic bmap update from ship radar.
radmap() is now radmap2()'s only caller. Inline radmap2() and
simplify. This cleans up a suspicious-looking use of xyas(): it
relied on the fact that owner == player->cnum if pr_flag.
shp_nav() and shp_nav_one_sector() printed both to their actor
argument and to ship owner. shp_nav_one_sector()'s use of xyas()
looked particularly suspicious: it passed actor, then printed the
result to the ship owner. Fortunately, actor and ship owner are the
same, since even deities can't navigate foreign ships. Normalize to
actor for consistency.
While there, rename shp_mess() to shp_stays().
lnd_mar(), lnd_sweep() and lnd_mar_one_sector() printed to the current
player, their actor argument, and to land unit owner.
lnd_mar_one_sector()'s use of xyas() looked particularly suspicious:
it passed actor, then printed the result to the current player or land
unit owner. Fortunately, all three are the same: all callers pass
current player for actor, and land unit owner is the same, since even
deities can't march foreign land units. Normalize to actor for
consistency.
While there, rename lnd_mess() to lnd_stays().
It passed def->own to lnd_sweep(), which looks like a bug. But it's
actually player->cnum there, because take_def() already set def->own
to player->owner: take_def() first changes the owner of the attacked
sector by calling takeover(), then updates def->own from that in
att_get_combat().
take_def() and ask_move_in() printed both to the current player and to
land unit owner. Their use of prcom() and xyas() looked particularly
suspicious: they used the current player, then printed the result to
the land unit owner. Fortunately, current player and land unit owner
are the same, since even even deities can't attack with foreign land
units. Normalize to current player for consistency.
Switch get_ototal(), get_oland(), kill_land() and move_in_land() to
current player as well.
The difference between the two is that PR() buffers partial lines, and
mpr() suppresses output to country#0. Doesn't matter when printing
complete lines to a country other than #0, e.g. the owner of a unit.
Don't tell him that it's his plane, he knows that.
Put a " -- " between "takes N%" and "aborted" / "shot down" for
ordinary flak as well, not just for flak vs. pinpoint bombing.
Reduce abort chance from 100-eff to 80-eff. Ordinary flak's abort
chance was reduced from 100-eff (if eff<80) to 80-eff in commit
0252d4a7, v4.3.6.
Report plane efficiency when it aborts, not 100 - efficiency.
Charge mobility proportional to damage, down to -32.
Since Empire 3 made option NEWPAF mandatory, checkabort is always
non-zero, and show implies checkabort != 1 and other == 0. Drop
unreachable code, and remove unused parameters checkabort and other.
Pass the more obviously correct plane_owner instead of player->cnum.
They're the same, actually.
When deities could still fly foreign planes (before commit 2023b47c),
they weren't. ac_encounter() updated the plane owner's in-memory
bmap, but wrote the current player's bmap to disk.
satdisp_sect() updated the in-memory bmap, but failed to write the
updates to disk. Its callers already update bmap from other sources,
so move this update there, and connect it to the existing write back.
The only user is reco(), so the restriction is fine. Several
functions called on behalf of mission_flags assumed it already:
plane_sweep(), sathead(), satdisp_sect(), satdisp_units(). Simplify
the rest accordingly: plane_sona() and ac_encounter() itself.
