nethack-gwaa-kiwi/nethack
1
0
Fork 0
Code Pull Requests Activity

stale lock picking context

Browse Source 
Lock context wasn't being cleared if it was for a container and that
container got destroyed.  Case discovered was forcelock() ->
breakchestlock() -> delobj() (sometimes the container is destroyed
rather than just breaking its lock) followed by #wizmakemap (replace
current level) and maybe_reset_pick() trying to check whether
xlock.box was being carried.  But being interrupted, destroying the
container or dropping it down a hole to ship it to another level, then
attempting to resume picking the lock would also find a stale pointer.
This commit is contained in:
PatR
2019-01-31 15:50:12 -08:00
parent ed79141463
commit 8bf16b940e
6 changed files with 40 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/fixes36.2
View File

@@ -1,4 +1,4 @@
$NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.241 $ $NHDT-Date: 1548937318 2019/01/31 12:21:58 $
$NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.242 $ $NHDT-Date: 1548978603 2019/01/31 23:50:03 $
This fixes36.2 file is here to capture information about updates in the 3.6.x
lineage following the release of 3.6.1 in April 2018. Please note, however,
@@ -357,6 +357,8 @@ smudging of an engraving has been relocated to after a succesful move
subject to the smudging
monster with multiple items in inventory could trigger 'dealloc_obj with nobj'
panic when turned into a statue if separate mon->minvent items merged
lock picking context could end up with stale container pointer if container
being forced/unlocked/locked got destroyed or sent to another level
Fixes to Post-3.6.1 Problems that Were Exposed Via git Repository