Crash dump forks a child to call abort(). abort() may flush or close
streams. This is unwelcome, because it can mess up streams in the
parent. Observed with the journal. Could theoretically also affect
commands info, read, turn, and wire; announcement expiry, and reading
of econfig and schedule.
Fix by using SIGABRT instead.
Note that flushing streams before fork() is not a sufficient fix,
because closing a stream can still move the file descriptor's file
position. Do it anyway, to ensure any buffered output is visible to
post_crash_dump_hook.
The commands to fly planes read the planes into a plane list, and
write them back when they land. If a plane changes in the file while
it is in that plane list, the changes get wiped out when the plane
lands, triggering a seqno oops.
This is not an issue as long as the complete sortie runs
uninterrupted, because that code takes care to update flying planes
only through the appropriate plane list.
However, the bomb command suspends the planes on a pinpoint bombing
run mid-air over the target sector to let the player choose targets.
This lets code run that *can* update flying planes, for instance the
edit command.
Fix by aborting changed planes, taking care not to clobber the
changes.
When bombing ships with a force containing both planes with and
without capability ASW, pin_bomb() could fail to report presence of
submarines, and could refuse to bomb ships when there were only
submarines. The culprit is pin_bomb()'s check for capability ASW: it
checked whether the first plane in the plane list was capable instead
of checking whether any plane in the list was capable.
A victorious attacker can move attacking land units into the newly
conquered sector or leave them behind. Normally, the player is asked
what to do, but when the land unit's army has already been told to
stay behind, or the command has been aborted, the land unit stays
behind without asking. In that case, a copy of the land unit made
right after the victory was written back. Any updates since the
victory were wiped out, triggering a seqno mismatch oops.
Fix by moving the re-read of the land unit in ask_move_in() out of the
prompt conditional.
check_loan_ok(), check_comm_ok() and check_trade_ok() should have been
changed to ignore timestamps when timestamps were added to their files
in commit a680c811, v4.3.12.
pthread.c's empth_select() returned -1 when empth_wakeup() interrupted
select(). The failure then got propagated all the way up, and the
player got logged out. Fix by returning 0 in that case. While there,
retry on EINTR, to match LWP. Also clarify comments.
Unused since 4.3.10. Can be used safely only in very special
circumstances.
Removal allows simplifying pthread.c and ntthread.c some. liblwp left
alone.
Make didn't remake sources.mk even though it was a phony target. I
don't understand why. But we can just as well create it in its only
user, dist-source.
Change s_commod() not to use the supply sink as source. As explained
in the message of the commit before the previous one, using the sink
as source makes it impossible for callers to safely keep a copy of the
sink across a supply call. All current users do that. Some were safe
anyway, some were not:
* fort_fire() was safe, because a fort draws shells only when it has
none.
* shp_fire() was unsafe for ships with capability supply and ammo use
greater than 1. No such ship exists in the stock game.
* shp_dchrg() was unsafe for ships with both capabilities dchrg and
supply. Same for shp_torp() and capability torp, and
shp_missile_defense() and capability anti-missile. No such ship
exists in the stock game.
* lnd_fire(), supp() and get_dlist() were safe, because they draw
shells only when they have less than their ammo need, and then they
don't supply any.
* mission_pln_equip() was unsafe when equipping planes with shells in
supply sources.
* landmine() was unsafe for land units with both capability engineer
and supply. No such land units exist in the stock game.
* load() and lload() were unsafe for loadable supply units, but the
supply use there was disabled in commit 65410d16 because of another
bug.
* ask_olist() and att_reacting_units() were safe, because
lnd_can_attack() excludes supply units.
In the stock game, planes flying interception or support missions,
abms intercepting ballistic missiles, launch of missiles or anti-sats
could conjure up shells, triggering a seqno mismatch oops.
In games with unusual customizations, this could also happen with
supply ships firing guns or torpedoes, dropping depth charges, or
shooting down marine missiles, and in the lmine command.
To implement the supply from self avoidance described in the previous
commit's message, s_commod() needs to be redesigned along the same
principles: take the sink as argument, update and put it. Also take
an item limit argument, and return whether supply request was fully
met.
Update sct_supply(), shp_supply(), lnd_supply() and
lnd_could_be_supplied(). The former three become straighforward
wrappers.
supply_commod() and try_supply_commod() are now unused, remove them.
The automatic supply interface has design flaws that make it hard to
use correctly. Its current uses are in fact all wrong (until commit
0179fd86, the update had a few uses that might have been correct).
Some of the bugs can only bite with land unit capability combinations
that don't exist in the stock game, though.
Automatic supply draws supplies from supply sources in range. Since
that can update any supply source in range, all copies of potential
supply sources a caller may keep can get invalidated. Writing back
such an invalid copy wipes out the deduction of supplies and mobility
from a source, triggering a seqno mismatch oops.
This commit redesigns the interface so that callers can safely keep a
copy of the object drawing the supplies (the "supply sink"). The idea
is to pass the sink to the supply code, so it can avoid using it as
source. The actual avoiding will be implemented in a later commit.
Copies other than the supply sink still need to be eliminated. See
commit 65410d16 for an example.
Other improvements to help avoid common errors:
* Supply functions are commonly used to ensure the sink has a certain
amount of supplies. A common error is to fetch that amount
regardless of how many the sink already has. It's more convenient
for such users to pass how many they need to have instead of how
many to get.
* A common use of supply functions is to get supplies for immediate
use. If that use turns out not to be possible after all, the
supplies need to be added somewhere, which is all too easy to
forget. Many bugs of this kind have been fixed over time, and there
are still some left. This class of bugs can be avoided by adding
the supplies to the sink automatically.
In fact, this commit fixes precisely such bugs in mission_pln_equip()
and shp_missile_defense(): plane interception and support missions,
missile interception (abms), launch of ballistic missiles and
anti-sats could all lose shells, or supply more than needed.
Replace supply_commod() by new sct_supply(), shp_supply(),
lnd_supply(), and resupply_all() by new lnd_supply_all(). Simplify
users accordingly.
There's just one use of resupply_commod() left, in landmine(). Use
lnd_supply_all() there, and remove resupply_commod().
Automatic supply always leaves enough food to avoid starvation in
supply sources, except for one case: when drawing supplies from the
sector containing the sink.
This behavior contradicted info supply. However, do_feed() used to
rely on it (it would have wiped out food without it). Supply use
there was removed in commit 7da69c92, so we can now fix this.
Affected by this is the automatic food supply of land units in combat,
and the food supply in commands supply, load and lload. Except supply
is disabled due to bugs in the last two.
When a supply request got served completely from a remote sector after
some other source had already provided some of it, the sector was
charged mobility for the complete amount instead of just the part it
actually provided.
Its implementation in s_commod() increases lnd_seqno even when
!actually_doit, which can cause spurious seqno oopses in callers of
lnd_could_be_supplied(). I can't be bothered to clean up this mess
right now, because recursive resupply is too dumb to be really useful
anyway: each step uses the first source it finds, without
consideration of mobility cost.
Being in supply is relevant for defending and reacting units. The
code used has_supply() to check that.
Contrary to its name, has_supply() does not check whether the land
unit has enough supplies to be in supply, but whether it has or could
draw enough. So, defending and reacting units did not actually draw
any missing supplies.
Fix that in get_dlist() and att_reacting_units() by calling
resupply_all(), then checking with new lnd_in_supply() instead of
has_supply(). The fix of att_reacting_units() is complicated by the
fact that it is also used in the strength command, and should keep not
drawing supplies there.
Rename has_supply() to lnd_could_be_supplied(). Replace its uses
immediately after resupply_all() by lnd_in_supply().
Running supply recursively here is problematic, because it can draw
supplies from the outer supply's destination, which can then end up
with less than it asked for.
Serving as supply source never puts a unit that is in supply out of
supply. So, the recursive supply here denies the sink its supplies to
put a supply unit somewhere else back in supply. That's robbing Peter
to pay Paul. Drop it.
The common supply code does not supply a land unit from the ship
carrying it, only resupply_all() does that, since 4.3.14. It would be
nice to fix the inconsistency by always supplying land units that way,
but that's relatively costly now, because of the supply code's design.
Just drop it for now.
Affects load and lload (except resupply is disabled there because it's
buggy), supply, assault and board.
It claimed ships and land units don't need shells if they can draw
them from a supply source. That was never true for ships, I believe,
and became wrong for land units in commit f6c87d21.
Don't claim "now out of supply" when actually out of mobility.
Don't claim "out of supply" when actually out of shells. A land unit
is out of supply when out of shells, but not necessarily the other way
round.
Reading the sector again invalidates the sector type check. Bug can
currently bite only when the deity redesignates the sector. Call
check_sect_ok() instead.
Food supply during update adds complexity to the update. How much
good it does to players is highly doubtful; certainly nobody can rely
on it. It isn't covered by the starvation command. Starving ships or
land units can steal enough food from their sector to make it starve,
too. Finally, the supply code is notoriously hard to use correctly.
We don't know of issues with the update's use, but we haven't
convinced ourselves that there aren't any either.
4.0.9 changed flak not to use up shells, but they still had to be
present. Drop that, because it doesn't really provide any value.
Moreover, this gets rid of the buggy flak shell supply code (seqno
mismatch oopses, lost supplies).
