]> granicus.if.org Git - nethack/commit
stale lock picking context
authorPatR <rankin@nethack.org>
Thu, 31 Jan 2019 23:50:12 +0000 (15:50 -0800)
committerPatR <rankin@nethack.org>
Thu, 31 Jan 2019 23:50:12 +0000 (15:50 -0800)
commit8bf16b940e15cac75cea2a4de92738c90fa71688
tree6755ef560686c391db0b79430615d210c5d1b88e
parented79141463e7f914453756ecc7b45c868409bd02
stale lock picking context

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.
doc/fixes36.2
src/cmd.c
src/do.c
src/lock.c
src/mkobj.c
src/shk.c