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

Wielding potions of blindness confers blindness resistance

Reported by arxanas, confirmed by ais523 and ishanyx

nhversion:
3.4.3

nhfrom:
Not presently known

hardware:
  Model Name:                 MacBook Pro
  Model Identifier:           MacBookPro8,2
  Processor Name:             Intel Core i7
  Processor Speed:            2.5 GHz
  Number of Processors:	      1
  Total Number of Cores:      4
  L2 Cache (per Core):        256 KB
  L3 Cache:                   8 MB
  Memory:                     8 GB
  Boot ROM Version:           MBP81.0047.B27
  SMC Version (system):       1.69f3
  Serial Number (system):     [redacted]
  Hardware UUID:              [redacted]
  Sudden Motion Sensor state: Enabled


software:
Unmodified 3.4.3

comments:
My dearest devteam,

I write to inform you of a most pressing bug in your game. 'Tis present in the source
release (nethack-343-src.tgz, MD5 21479c95990eefe7650df582426457f9), and as such remains
present in all compilations of our beloved game. To reproduce the bug, one might partake
in the following steps:

1. Get a potion of blindness.
2. Wield it (as your primary or alternate weapon), or ready it in your quiver.
3. Allow a yellow light to explode at you.

Despite the expected behavior of a yellow light causing you blindness, you remain
unaffected. This is a most grievous error, as one could simply saunter through the dungeon
with nary a thought for the poor yellow lights, who give their lives in vain. Even worse
is that archons too cannot blind you, for the issue resides in resists_blnd, and archons
call this function to gaze.

I know that you are all hard at work making the next version of NetHack for us all, so I
deigned to save you some time by providing a possible patch. It took me the better part of
an hour to devise, as the coding involved is rather in-depth and hard to follow. I hope
you incorporate it into the forthcoming new version of NetHack (which I am sure will be
here sometime soon), as I would hate to play the game immune to yellow lights.

Thanks for all your hard work,
[redacted]

(attached documents):
patch.diff:

Only in nethack-3.4.3-patched/: .DS_Store
diff -r nethack-3.4.3/src/mondata.c nethack-3.4.3-patched/src/mondata.c
126,127c126
< 	    if ((o->owornmask && objects[o->otyp].oc_oprop == BLINDED) ||
< 		    (o->oartifact && protects(AD_BLND, o)))
---
> 	    if (o->oartifact && protects(AD_BLND, o))

Turn alternation failure with 24 movement energy

Reported by ais523

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.

Grammar and message-related errors

Reported by Grunt

mailversion:
1.45

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
Probably unimportant, but: Intel Core 2 Quad Q8400 @ 2.66 GHz, 4GiB
memory, 2TB disk space.

software:
Gentoo Linux; NetHack 3.4.3 built using GCC 4.6.2.

comments:
During development of a variant, I've come across the following which
may constitute bugs in NetHack 3.4.3, as checked against a build
unmodified except for one configuration option (#define LINUX).

* When reverse-genociding a nearly-extinct monster, sometimes only one
  monster is generated, but the message is still "Sent in some <plural
  of monster>.", suggesting more than one is generated.  This is best
  illustrated with Nazgul - generate eight Nazgul and then
  reverse-genocide them to see "Sent in some Nazgul[s]." (depending on
  if you're looking at this in a build that has fixed C343-8 or not).
  Under these cases, a more accurate message would be "Sent in a
  Nazgul".

* When attacking a monster carrying a stack of destroyable items with a 
  weapon that destroys them (e.g. scrolls/spellbooks/potions with Fire
  Brand, potions with Frost Brand), if exactly one item of the stack is
  destroyed, the object name is plural, but the message indicating that
  it was destroyed is not (e.g. "The dwarf king's scrolls labeled ELAM
  EBOW catches fire and burns!").  Perhaps the message should use the
  same logic as when the player is hit by an item-destroying attack,
  yielding, e.g., "One of the dwarf king's scrolls labeled ELAM EBOW
  catches fire and burns!".

* The death reason given for choking on an artifact is "choked on {a|an}
  <object>", which can be inappropriate when quest artifacts are
  involved - e.g. "choked on an Eye of the Aethiopica", inconsistent
  with the use of "[Tt]he" as a prefix everywhere else they are
  mentioned.  In the case of quest artifacts, this probably should be
  "choked on The Eye of the Aethiopica", and for other artifacts,
  perhaps "choked on Grayswandir" (skipping the article).  (It could be
  argued that a further bug is treating the unidentified and identified
  cases of artifacts differently, e.g. "choked on a silver saber named
  Grayswandir" in some cases as opposed to "choked on [a] Grayswandir"
  in all cases, particularly when working in a build where objects are
  able to be named after artifacts - "a silver saber named Grayswandir"
  without actually being Grayswandir - as the deaths in those two cases
  would be indistinguishable.)
 
* When a player zaps a wand of striking or casts force bolt at a monster
  that is magic resistant, no "Boing!" message is generated; all other
  cases (player against self, monster against player, and monster
  against monster) generate this message, which is inconsistent.

I hope that pointing out these bits of behaviour is useful to all of
you.

Worn monster equipment can be picked up while engulfed

Reported by bcode

The ID number for this message is '#H2816'

mailversion:
1.45

nhversion:
3.4.3

nhfrom:
Our 3.4.3 source release, unmodified

hardware:
It's probably unimportant, but I've tested this on a machine with a
1.5 GHz Intel Pentium 4 processor and 896420 kB of memory.

software:
Unmodified (except for config.h/unixconf.h and Makefiles) NetHack 3.4.3,
built from source with GCC 4.6.3 running on a Linux 2.6 system.

comments:
A player can pick up worn equipment from inside a monster while
engulfed by it. The object still has its owornmask set, so it will be
displayed as "(being worn)" and cannot be dropped; however, the player
is not actually wearing it, so it cannot be removed. Trying to put it
on, on the other hand, gives a message about it being already worn.

Trying to remove the object (by selecting it when asked what to remove)
will output an impossible() message:

| select_off: a blessed amulet of life saving (being worn)???
| Program in disorder - perhaps you'd better #quit.

I think it is easiest to reproduce this in wizard mode; create a
soldier and get him to pick up and put on an amulet of life saving,
then enable #monpolycontrol and polymorph him into an engulfer, for
example a fog cloud. Get engulfed by the fog cloud and pick up the
(worn) amulet of life saving inside.

As a workaround, saving and loading the game seems to make the amulet
removable again.

Jumping into portals can print messages out of order or incorrectly pick up items

Reported by ais523

mailversion:
1.45

nhversion:
(please select version)

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
bugs in general 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:
First, the bug (found today): if a player attempts to jump into or
over a magic portal (I tested with the jumping spell, but suspect
it would work the same for #jump), and there's an item on the square
that the player passes over immediately before reaching the portal,
then the game prints the messages for the portal (while showing
the player standing on the square before), then the messages for
the item, then autopicksup the item (if autopickup is on and set to
pick up that sort of item), and then the player actually moves to the
portal destination. Expected behaviour is for the game to not mention
or pick up the item (as would happen if no portal is involved).

I'd again like to encourage the devteam to cooperate more with
the NetHack development community as a whole on the whole on
bugfixes. Many bugs appear to be already known but not on the
devteam, and for many other bugs, the descriptions on the website
are insufficient for us to work out what the bug is about, or find or
reproduce it ourselves. (Imagine if I'd reported this bug simply as
"Messages sometimes appear out of order when jumping"!) Incidentally,
the bug that's been confusing the community the most is SC343-18;
from its description, it seems to be connected to C343-231, but we
have no idea what causes SC343-18 or even what the bug description
means. Is there some way we can get more detailed descriptions of
official bugs, like the ones we send to you when we find them?

Probably the gold standard for understanding what's causing a bug
is an explanation based on the code; the diff that fixes the bug
is the method of explaining this that causes the least extra work,
but I understand that the DevTeam badly wants to avoid releasing
any code until it's ready (even though this means that nobody else
can help them get it ready on time; and it's also meant that line
numbers in your development version have likely drifted away from
line numbers in, say, community efforts to produce fixed versions of
NetHack, such as NetHack 4, which would not even be as necessary if
the bug fixes were public). In the particular case, the code-based
reason for the bug is that hurtle_step(), which is responsible for
determining whether squares are passable when jumping or hurtling,
calls the code for handling a magic portal when the user reaches
it and then returns FALSE, meaning that walk_path() treats the
portal like a wall. Because the portal code just prints messages
and then schedules a goto, you get the messages first, then the
character stops (and thus picks up items, if necessary), and then
the scheduled goto happens. I don't currently have a working fix
for the bug, although the most obvious methods of fixing it to
me would involve making the jump/hurtle code check for traps when
leaving or landing on squares, as opposed to before entering them.

--
Alex Smith
NetHack 4 maintainer