Fix message when door explodes while unlocking it. #1
Labels
good first issue
Good for newcomers
Comments
elunna
pushed a commit
that referenced
this issue
Jan 1, 2024
If tutorial is entered, we get following leak on exit:
=================================================================
==81358==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x7f6996edefdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x5601c255bcbb in alloc /home/miku/src/NetHack/src/alloc.c:71
Indirect leak of 5064 byte(s) in 3 object(s) allocated from:
#0 0x7f6996edefdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x5601c255be1e in alloc /home/miku/src/NetHack/src/alloc.c:71
#2 0x5601c255be1e in dupstr /home/miku/src/NetHack/src/alloc.c:236
SUMMARY: AddressSanitizer: 5160 byte(s) leaked in 6 allocation(s).
Fix this by freeing the cloned selection before returning.
elunna
added a commit
that referenced
this issue
Dec 13, 2024
… xNetHack/Fourk). Ported straight from xNetHack's implementation, based mostly off of commit 00fec3777: 'This is an implementation of what is commonly termed the 'dtsund-DSM' proposal (http://roguelikes.live/nh4-bugzilla/show_bug.cgi?id=629) by dtsund and jonadab: rather than having dragon scale mail objects as their own armor, create a system by which the player can make 'dragon-scaled' armor - a regular leather armor, chain mail, etc, with dragon scales embedded into it, conferring the same extrinsic they give normally. This implementation is based on NetHack Fourk's, but with heavy adjustments because a lot of the core NetHack code is changed there. The main reason for replacing dragon scale mail with this new system is that dragon scale mail is a supremely optimal choice of armor and makes armor strategy much less interesting. To summarize, dragon scale mail was ALL of the following simultaneously: a) lightweight b) higher in base AC than all other armors c) naturally erodeproof d) transparent to spellcasting e) available before the Castle and sometimes even the Quest, or from the first early wish (and it was the #1 most common early wish) f) a provider of a powerful extrinsic (reflection, magic resistance) Once dragon scale mail became available, there was absolutely no reason not to wear it. With it out of the picture, though, armor strategy becomes relevant again past the first few dragons in the game, because the player ultimately needs to decide on one of the base armors to wear, and will have to continue considering the tradeoffs that come with it. This also is a big step forward for the xNetHack philosophy of encouraging found objects over wished ones. Previously, if you found a really nice mithril chain mail or something, you would know you would only keep it around until you could acquire dragon scale mail, and then ditch it. Now the best option is to find a good color of dragon scales, attach it to your armor, and keep using it. That said, I don't want this to come across as a nerf for its own sake. I plan on mitigating the weight factor by implementing another variant's adjustments to body armor weight while it's being worn. This is also why dragon scales still give 3 AC when worn as a cloak and give +3 AC to any scaled armor: it seemed like a pointless nerf to drop the AC of scales to zero (meaning you can do pretty well AC and extrinsic wise by wearing scaled armor and scales of a different color over top, at the cost of having zero MC), and scaled armor ought to derive _some_ benefit from its impervious dragon scales other than the extrinsic. Another difference from Fourk is that xNetHack scaled armor is not automatically erodeproof. Mainly because it seemed more interesting to keep around the possibility of the player's armor continuing to be vulnerable to erosion past the midgame. I assume most players will erodeproof their armor or put scales on armor made of a material that is naturally erodeproof, anyway. As in Fourk, I didn't bother implementing the part of the original proposal where you can pry the scales back off armor with a tin opener, because it seemed really weird flavor-wise and I didn't want to make an occupation for spending multiple turns prying scales off. As in Fourk, if you polyself and merge with your scaled armor, you get it back after unpolymorphing, which is an intentional buff. Doesn't seem right to have its scales unmeld from it and cost the player another enchant scroll to put the scales back on.'
elunna
pushed a commit
that referenced
this issue
Dec 23, 2024
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After fixing a crash while unlocking an exploding door (0022651) I noticed that we see:
"You succeed in unlocking the door"
door explode message
"You stop unlocking the door"
Since we already got a message for unlocking the door AND the door doesn't exist, it makes this message quite awkward.
Fixing this is a bit tricky since the unlocking and door explosion are both inside the picklock occupation. Help would be greatly appreciated on this issue.
The text was updated successfully, but these errors were encountered: