If freedynamicdata() gets called twice, for whatever reason, a "double free" can occur.
warning: 44 ./nptl/pthread_kill.c: No such file or directory
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff7c8b26e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff7c6e8ff in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff7c6f7b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff7e148d7 "%s\n")
at ../sysdeps/posix/libc_fatal.c:132
#6 0x00007ffff7ceefe5 in malloc_printerr (str=str@entry=0x7ffff7e17bf0 "free(): double free detected in tcache 2")
at ./malloc/malloc.c:5772
#7 0x00007ffff7cf154f in _int_free (av=0x7ffff7e49ac0 <main_arena>, p=<optimized out>, have_lock=0)
at ./malloc/malloc.c:4541
#8 0x00007ffff7cf3d9e in __GI___libc_free (mem=0x555555ad82a0) at ./malloc/malloc.c:3398
#9 0x00005555557c12e9 in free_rect () at rect.c:48
#10 0x00005555557d77a2 in freedynamicdata () at save.c:1240
#11 0x0000555555682754 in nh_terminate (status=0) at end.c:1671
#12 0x000055555589af15 in opt_terminate () at ../sys/unix/unixmain.c:768
#13 0x000055555589af7a in after_opt_showpaths (dir=0x0) at ../sys/unix/unixmain.c:796
#14 0x0000555555693dd9 in do_deferred_showpaths (code=0) at files.c:4491
#15 0x0000555555778405 in initoptions () at options.c:6948
#16 0x0000555555899cd9 in main (argc=2, argv=0x7fffffffdad8) at ../sys/unix/unixmain.c:151
This helps avoid a potential chicken-and-egg scenario
with the system configuration file (sysconf).
If sysconf wasn't accessible at the expected location, it
caused an immediate exit, without relaying any helpful
information. That happened even when using:
'nethack --showpaths'
That's particularly unhelpful, because the --showpaths
output might have been useful towards understanding where
NetHack was looking for such things.
That left you without an easy recourse to identify where
the game is looking for the sysconf file. That might be
especially troublesome if you didn't build the game
yourself.
Be more consistent in the use of path separators.
Add a second version of Makefile variables that contain paths,
one with a trailing separator, and one without (prefixed with R_
for use in Makefile rules).
Also, in dat/luahelper,
Updates due to correspond to the Makefile.nmake changes.
Add Makefile variable AWK to use $(AWK) instead of hardcoded awk.
Use by:
make -f dat/luahelper [target]
Target examples:
Visual Studio nmake : make -f dat/luahelper devhelp-nmake >file.txt
msys2 GNUmakefile : make -f dat/luahelper devhelp-msys >file.txt
Xcode project.pbxproj: make -f dat/luahelper devhelp-xcode >file.txt
all: generate txt files for all the above
GitHub 1343 report by @ars3niy:
"When you are blind and see with telepathy a monster whom you then hear read
a scroll, said monster turns into an "I". While it reveals which one exactly
read the scroll, it is strange that you can no longer see it with telepathy
until it moves to another square."
Fixes#1343
There was a transcription error in the comments in cstd.h for
the standard list of header files, where only the description
remained for <stdlib.h>, not the name of the file itself.
Remove several extraneous inclusions of the standard C99 headers.
Tested on the following afterwards:
Linux (using hints/linux.370) including tty, curses, qt6, and X11
macOS (using hints/macOS.370) including tty, curses, qt5, and X11
Windows MSYS2 using sys/windows/GNUmakefile
Windows Visual Studio using sys/windows/Makefile.nmake
msdos cross-compile on Ubuntu using djgpp cross-compiler
Issue reported by k21971: winter wolf cub and hellhound pup were
defined with alignment -5 (chaotic) while winter wolf and hellhound
were 0 (neutral).
K2 suggested that winter wolf plus cub both be neutral and hellhound
plus pup both be chaotic but I've gone another way: both cub and
pup are now 0 and both adults are -5.
Fixes#1340
Various bits I had in progress before Michael's commit.
Mainly forget engravings when bones are saved instead of leaving them
flagged as seen for the next hero who gets the level.
Since EDITLEVEL is being incremented for the previous patch anyway,
add the "name_from" bit to the obj struct now, as groundwork for
the code change mentioned in a TODO comment in bones.c:
/* strip user-supplied names */
/* Statue and some corpse names are left intact,
presumably in case they came from score file.
[TODO: this ought to be done differently--names
which came from such a source or came from any
stoned or killed monster should be flagged in
some manner; then we could just check the flag
here and keep "real" names (dead pets, &c) while
discarding player notes attached to statues.] */
if (has_oname(otmp)
&& !(otmp->oartifact || otmp->otyp == STATUE
|| otmp->otyp == SPE_NOVEL
|| (otmp->otyp == CORPSE
&& otmp->corpsenm >= SPECIAL_PM))) {
free_oname(otmp);
}
Also, the bitfield per-byte groupings identified in the struct
weren't accurately reflected, so rearrange the Bitfields,
and correct the per-byte groupings.
This invalidates existing save files and bones.
GitHub issue reported by ars3niy:
https://github.com/NetHack/NetHack/issues/1303
@ars3niy commented on Oct 27:
Stepping on a square with a dust or "graffiti" engraving while blind
produces no message because presumably you can't read them by swiping
the floor with your hands, however the engraving glyph still shows up on
the map afterwards. While this helps zen players, it looks like a bug.
@ville-v commented 3 days ago:
Searching while blind also reveals the engravings. Here is a save file
demonstrating the issue.
[...]
This adds an erevealed bit to engravings, to accompany the the eread
bit that is already there.
eread: refers to the text of the engraving
erevealed: refers to the engraving map symbol
Hopefully, this resolves issue 1303 without creating additional bugs.
This invalidates existing save files and bones.
Fixes#1303
Issue reported by elunna: the message given when zap_over_floor()
hits iron bars with lightning or acid was substituting a couple of
words or phrases in the wrong order, resulting in
|The {melt|dissolve} iron bars somewhat but remain intact.
when the iron bar location is flagged as non-diggable. It should be
|The iron bars {melt|dissolve} somewhat but remain intact.
Not mentioned: the corresponding message for locations that aren't
flagged as non-diggable used "melt" unconditionally. Change it to
keep "melt" for lightning but switch to "corrode away" for acid.
Fixes#1342
After finding a trap on a chest or a large box, remember it
as trapped: "You see here a trapped large box."
Randomly generated chests and boxes can be obviously trapped.
Allow defining obviously trapped containers via lua.
Invalidates saves and bones.
A fix in Janurary to avoid appending engraving text or headstone
text when examining a map location where a monster or object covers
the engraving or headstone inadvently broke the /e and /E variations
of the '/' command, which is intended to list such text even when
covered.
This build command will include line number info, gdb.exe or nhgdb.bat in the package:
make CROSS_TO_MSDOS=1 WANT_DEBUG=1 package
This build command will not include line number info, gdb.exe or nhgdb.bat in the package:
make CROSS_TO_MSDOS=1 package
We can't rely on doopen_indir return value to
check whether hero moved and opened a door.
Instead, explicitly check whether the door is still
closed, and whether hero moved.
The ones below marked "left,revisit" might be worthy of code changes
explode.c:removed: arg sx,sy passed to breaks() are coordxy and so are the parameters
invent.c: removed: discover_artifact() parameter is xint16, so change cast to match
mail.c: removed: gv.viz_rmin[] contains coordxy's, and enexto() 2nd param is too
mkmaze.c: removed: x, y are coordxy and so are cc->x, cc->y
mkroom.c: removed: tx, ty are coordxy and so are parameters to occupied()
mplayer.c: left,revisit: x,y declared int, but mk_mplayer() params are coordxy
sp_lev.c 2890: left alone: x,y declared int, but is_ok_location() params coordxy
sp_lev.c 4114: left alone: cast from lua_Integer
sp_lev.c 4123: left alone: cast from lua_Integer
sp_lev.c 4650: left alone: cast from lua_Integer returned from lua_tointeger
sp_lev.c 4765: left alone: cast from int_Integer returned from lua_tointeger
sp_lev.c 4772: left alone: cast from int_Integer returned from get_table_int
teleport.c 366: left alone: cast from int returned from rn2()
timeout.c 2171: left alone: cast from long
vault.c: left,revisit: guardx,guardy declared int, but bestcc fields are coordxy
worm.c 791: left,revisit: wseg.wx, wseg.wy are coordxy, so are nx, ny, but not
ox, oy; why are ox, oy needed at all?
worm.c 955: left alone: wx, wy are coordxy, wseg_at() params are int x, int y
zap.c 5061: left alone: cast from long
The WANT_DEBUG=1 will cause the cross-compile to include line
number information in the NetHack executable, useful for
backtraces and gdb debugging sessions.
How a developer can use the optional deploy-to-dosbox target:
make CROSS_TO_MSDOS=1 WANT_DEBUG=1 dosbox=/mnt/c/dosbox deploy-to-dosbox
where dosbox= points to the directory which will be mounted for
your drive in dosbox
THe deploy-to-dosbox recipe ensures that a target copy of gdb.exe
ends up alongside nethack.exe at the target, including:
- placing the source code that gdb requires on the target
in the nhsrc subfolder.
- an nhgdb.bat that supplies the right switches to gdb
for locating the NetHack sources.
ENHANCED_SYMBOLS is defined by default in config.h.
The msdos build tried to #undef ENHANCED_SYMBOLS
in tilemap.c, but doing it in there created a mismatch
between the data struct definition for glyph_map in wintype.h
and the initializers generated in tilemap.c
Move the msdos build catch for ENHANCED_SYMBOLS to
one single place in config1.h so that the code and data agree.
