Bugs in NetHack 3.4.3/Reports

The official list of bugs in NetHack 3.4.3 gives very little information about the bugs in question. This page archives the known original bug reports sent to the DevTeam, to give more information and insight into the bugs.

C343-403

Reported by ais523, although it was well known in the NetHack community before the report

The ID number for this message is '#H2161'

mailversion:
1.41

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB
memory and 4 GB swap, and an Intel U2700 1.3GHz processor. (The bug
has been verified on multiple patched/unpatched versions of NetHack,
on multiple sets of hardware, including public servers.)

software:
Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled
from unmodified (apart from config.h/unixconf.h and makefiles)
official NetHack 3.4.3 sources compiled for Unix-like systems using
gcc 4.4.1. (Also probably irrelevant, given the above.)

comments:
There's a huge inconsistency in the way that writing scrolls via magic
marker works; in particular, it depends on interface details that
should be irrelevant. These checks were done as an unlucky non-wizard
to minimize the chance of false positives due to writing the scroll by
chance rather than due to having a 100% chance:

1. trying to write unIDed scroll by label:
"What type of scroll do you want to write? KIRJE" fails
2. trying to write unIDed scroll by actual type:
"For what do you wish? scroll of fire"
"What type of scroll do you want to write? fire" fails
3. trying to write called scroll by label:
"Call a scroll labeled KIRJE: X"
"What type of scroll do you want to write? KIRJE" succeeds
4. trying to write called scroll via user-given name:
"Call a scroll labeled FOOBIE BLETCH: wished-for"
"What type of scroll do you want to write? wished-for"
"There is no such scroll!"
5. trying to write called scroll via actual type:
"What type of scroll do you want to write? fire" succeeds
6. trying to write an IDed scroll via label:
(identify YUM YUM as magic mapping)
"What type of scroll do you want to write? YUM YUM" succeeds
7. trying to write an IDed scroll via actual type:
"What type of scroll do you want to write? magic mapping" succeeds

The major inconsistencies here are between cases 1 and 3, and between
cases 2 and 4. Case 3 implies that it's possible to copy a scroll
you've ever owned, even if you don't know what it does; case 1 implies
that it isn't. It's also incredibly unintuitive, if it makes sense at
all, that giving a nickname to a scroll is necessary to be able to
copy it.

The inconsistency between cases 2 and 4 is much worse, and I've seen
people exploit it on public servers. Suppose a player has ten
unidentified scrolls, and doesn't know what any of them do, but
suspects, say, that at least one is enchant armor. All they have to do
in order to write an enchant armor scroll is to name all ten of those
scrolls via #name-n, and then write enchant armor; if they had one in
inventory to name, they write the scroll correctly, even if they
didn't know /which/ of those ten scrolls it was. This doesn't make a
whole lot of sense, especially as a mechanism for identifying items.

The culprit is line 200 of write.c, which checks to see if a scroll of
the type given by the player has been called (i.e. given an
oc_uname). This check is dangerous without additional safeguards, as
it can let the scroll be written even if the player has no idea what
it is.

C343-409

Reported by ais523

The ID number for this message is '#H2210'

mailversion:
1.41

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB
memory and 4 GB swap, and an Intel U2700 1.3GHz processor.

software:
Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled
from unmodified (apart from config.h/unixconf.h and makefiles)
official NetHack 3.4.3 sources compiled for Unix-like systems using
gcc 4.4.3

comments:
If a player applies an unlocking tool (key, lockpick, credit card) at
an empty doorway containing a mimic pretending to be a door, the game
says "that doorway has no door", rather than reacting appropriately to
the presence of the mimic (say, by waking it and making the player
stick to it, or adding the lockpick to the mimic's inventory with an
appropriate message). The easiest way to reproduce this is in wizard
mode, by standing next to a doorway without a door, and repeatedly
doing control-G large mimic.

The bug's caused by a logic problem in src/lock.c. The check starting
at line 364 checks for mimics, but only for the purpose of not
printing any monster-related messages. Some time before line 385,
there needs to be code to allow for the possibility that in addition
to having a doorway on the square (accomplishable via having a doorway
without a door, which is still IS_DOOR internally), there's also an
apparent door in the doorway which is actually a mimic; the character
would believe there was an intact lock on the square even though they
game knows there isn't.

I would make and supply a patch for this bug, but as the README says,
"we will assume your code is synchronized with ours"; and I don't have
anything newer than 3.4.3 handy to patch against (and I suspect
patches against 3.4.3 wouldn't apply; you've likely changed your code
as extensively as I've changed my local copy in an attempt to make a
fork, but I test all bugs I report against the official 3.4.3
source). If you think a patch would help, let me know and I'll try to
provide one.

C343-421

Reported by ais523

The ID number for this message is '#H2142'

mailversion:
1.41

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB
memory and 4 GB swap, and an Intel U2700 1.3GHz processor.

software:
Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled
from unmodified (apart from config.h/unixconf.h and makefiles)
official NetHack 3.4.3 sources compiled for Unix-like systems using
gcc 4.4.1

comments:
Even after 6 years, it seems that new bugs, or at least buglike
behaviour, is still being discovered in NetHack. Is it intentional
that it's possible to avoid going through all the levels in Gehennom
on the "ascension run" (bringing the Amulet to the surface)?

The issue in this case is that it's possible to use the magic portal
leading to the Wizard of Yendor's Tower to skip several levels on the
way up. Although the player is incapable of leaving the tower (via any
method that works whilst holding the Amulet other than going back the
way they came) and thus this would seem to prevent this being used for
a shortcut, it's possible to drop the Amulet, then teleport it out of
the tower (with a wand of teleportation). Because the player's no
longer holding the Amulet, they can then #sit back on the portal to
leave the tower, level teleport back to the level the Amulet is on
(possible because they aren't holding it), and pick it up, this time
/outside/ the tower. (As an amusing aside, the fact that it's possible
to level-teleport past the intervening levels on the way down makes it
possible to not generate the levels in question at all.)

C343-425

Reported by ais523

mailversion:
1.42

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
Probably irrelevant, but it's a Toshiba Satellite netbook with 3
GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor.

software:
Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled
from unmodified (apart from config.h/unixconf.h and makefiles)
official NetHack 3.4.3 sources compiled for Unix-like systems using
gcc 4.4.3

comments:
A bug which was just discovered today in my unfinished NetHack fork
AceHack: a player was riding through the dungeon and stepped on awel
landmine, and his warhorse survived the explosion but died from the
fall. This lead to his dexterity permanently decreasing by one point.

Investigation on an unmodified version of NetHack shows that the
bug was inherited from there. The culprit is src/steed.c, line 527
(in NetHack 3.4.3; it's line 532 in AceHack, and I have no idea
what line it is in NetHack 3.5, even though obviously that would be
the most useful line number to give), which sets the wounded legs
intrinsic and extrinsic values to 0 without removing the dexterity
adjustment. Although this could be fixed at that point in the code,
it's probably easier to do it by calling the appropriate functions
instead (adjusting for the change in ride state).

C343-426

Reported by ais523

mailversion:
1.42

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
Probably irrelevant, but it's a Toshiba Satellite netbook with 3
GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor.

software:
Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled
from unmodified (apart from config.h/unixconf.h and makefiles)
official NetHack 3.4.3 sources compiled for Unix-like systems using
gcc 4.4.3

comments:
If a level is almost but not entirely full of monsters, then a player
hiding on the ceiling (after using #monster in any p or t form),
then when a monster moves onto the player's square, the player
falls to the nearest unoccupied square that the monster didn't come
from, even if it's over the other end of the level. There are no
restrictions on this, so it can be used to, say, cross the Plane of
Air or Astral in one turn, or escape from the Wizard of Yendor's
tower (or phase into it, but that's less useful because there are
various standard ways of luring him out, which as far as I know
are intentional; let me know if they're bugs and I'll report them).

The culprit is a use of enexto() without any sort of check,
on src/mhitu.c line 362 (in NetHack 3.4.3); the check is made
before moving the monster, even though the monster vacates the
square in question, so it won't hit the square that the monster was
occupying. (Every other use of enexto() in the 3.4.3 source to find a
location to place the player also has a check on the maximum distance
that the player can be moved; I obviously can't check to see if more
buggy uses have been introduced in a development version.) The most
obvious fix is simply to make the player and monster swap places,
although that would have issues where long worms were involved.

C343-428

Reported by ais523

mailversion:
1.42

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB
memory and 4 GB swap, and an Intel U2700 1.3GHz processor.

software:
Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled
from unmodified (apart from config.h/unixconf.h and makefiles)
official NetHack 3.4.3 sources compiled for Unix-like systems using
gcc 4.4.3

comments:
This bug was found in a collaboration between me and dwangoAC (we're
trying to determine the theoretically fastest turncount you can get
for a game of NetHack). When a cockatrice nest (the special room)
generates, all the statues in it are always of giant ants. This is
because the code just doesn't initialise the monster type (corpsenm)
of the statues anywhere; mkroom.c:346 calls mk_tt_object requesting a
STATUE, yet mk_tt_object explicitly asks for no initialisation on the
statues it creates (mkobj.c:1043). The comment on the line above is
incorrect, or at least incomplete; it states that it prevents
generation of statue contents, but the lack of initialization also
prevents the statue's corpsenm being set by mksobj like it normally
would be. (In case it matters, and in _tt_-related functions it might,
my test case was with a blank high score table.)

It's kind-of interesting that this wasn't noticed earlier; perhaps
players tend not to pay attention to the statues around cockatrice
nests because they're too busy worrying about the cockatrices?

Unnumbered bugs

Turn alternation failure with 24 movement energy

mailversion:
1.45

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, but modified

hardware:
Using a qemu virtual machine with QEMU Virtual CPU version 0.12.3,
with 614196 kilobyes of disk space, and 56364 kilobyes of
memory. (We're using snapshots of the virtual machine for more easily
reproducible bug testing.)

software:
Using a version of 3.4.3 modified to show the remaining movement
points of players and monsters, in order to more easily track the bug
down. I don't think I modified anything that would affect the bug (and
besides, I've already tracked it down from the source). Compiled with
gcc 4.4.3. The virtual machine is running Linux 2.6.32.

comments:
A short and sweet bug report: turn order becomes inconsistent with the
rest of the game when a player has 24 movement points exactly, and a
monster has at least 24. Normally, after the player takes their
action, monsters will get one action in response, then (if the player
has actions left in the turn) the player will get to take another
action. However, if the player has 24 movement points exactly, their
action will take them down to 12, at which point the monsters will get
to take all their remaining actions at once, and the player will get
the last action in the turn, rather than alternating turns like usual.

The dependence on the exact number of movement points is weird and
seems to be a bug. The offending line is, in 3.4.3, src/allmain.c line
79 (sorry I can't give you a line number from the bugfixed and
feature-added version of NetHack you're presumably working from, but I
haven't seen it). "youmonst.movement > NORMAL_SPEED" should be
"youmonst.movement >= NORMAL_SPEED".

Thanks to dwangoAC, who found this bug, and the testing system he made
to help me reproduce events in NetHack games under controlled
circumstances. Obviously, being able to rewind games and do something
else is even worse than savescumming from an ascension perspective,
but it helps very much when finding bugs.