search

elunna / hackem

SlashEM forked Unto Evil with a Splice of X and a dash of THEM.
Other
23 stars 8 forks source link

splitobj when a monster is picking up gems in mpickstuff #485

Closed elunna closed 11 months ago

elunna commented 11 months ago

Likely related to 00352c884 Fix: Monsters will pick up partial stacks From EvilHack commit 4dde18ca6fda25d0141c9579dc8dc76a997c47c2.

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=139685586077632) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
(rr) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=139685586077632) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=139685586077632) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=139685586077632, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f0b15c1a476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007f0b15c007f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x000055b5ee95f399 in NH_abort () at end.c:236
#6  0x000055b5ee96650c in panic (str=0x55b5ef49da80 "splitobj") at end.c:803
#7  0x000055b5eec8dc99 in splitobj (obj=0x60b0000453d0, num=-10) at mkobj.c:470
#8  0x000055b5eececb87 in mpickstuff (mtmp=0x6110000e3700, str=0x55b5ef4ac820 <gem_class> "\r") at mon.c:2361
#9  0x000055b5eeda3636 in m_move (mtmp=0x6110000e3700, after=0) at monmove.c:2106
#10 0x000055b5eed87b40 in dochug (mtmp=0x6110000e3700) at monmove.c:994
#11 0x000055b5eed71dc7 in dochugw (mtmp=0x6110000e3700) at monmove.c:181
#12 0x000055b5eece0eba in movemon () at mon.c:1617
#13 0x000055b5ee66023c in moveloop (resuming=0 '\000') at allmain.c:247
#14 0x000055b5ef37456b in main (argc=0, argv=0x7ffc3f673768) at ../sys/unix/unixmain.c:353
elunna commented 11 months ago

The gems in question are red glass. / #define WORTHLESS_PIECE_OF_RED_GLASS 664 /

The monster picking up is: #define PM_ROCK_MOLE 239

Ok interesting, maybe it's trying to pickup after eating?

The code where the panic is happening is this:

    if (obj->cobj || num <= 0L || obj->quan <= num)
        panic("splitobj"); /* can't split containers */

At this point, num is -10. Which seems weird? Lets see where that comes from. It's calculated in can_carry(). I set a break on can_carry. When we first enter this function, num is 1. It then returns after hitting this block:

if (curr_mon_load(mtmp) + newload > max_mon_load(mtmp)) {
  if (otmp->owt == LARGEST_INT)
     weightper = (int) ((((long) otmp->owt) - 1 + otmp->quan) / otmp->quan);
  return (max_mon_load(mtmp) - curr_mon_load(mtmp)) / weightper;

I think something is wrong with the weightper calc because it equals 1063727024

Is this because it's a quantity of 1?

elunna commented 11 months ago

More info: The rock mole was carrying a cram ration, weighing 20.

max_mon_load is calculating that the rock mole can carry a max of 10.