Bug: Crash happening upon monster death

[Magnate]

The borg might be a helpful tool, I'm sure you could reproduce the bug semi-regularly with it.

Unfortunately the borg isn't in the official repo - it's recently been updated to 3.2.0, but things have changed again since then.

[d_m]

No, I can only reproduce it when it pops up at random, and it is not at all reliable. You mentioned EXEs and not being able to reproduce it, so I assume you are on Windows? I am on Linux, so maybe it is a platform-specific thing. However, I dual boot to Windows, so if you want me to test something in Windows, I can still do it.

Actually the opposite. I run Linux and had assumed you were on Windows.

[jens]

Well I'm on Windows, and I had it first ;-)

[ChodTheWacko]

Do you have a stack?

It sounds like you can compile Angband yourself, so why not just compile the whole thing in debug mode, and then always play with gdb attached? That way next time it crashes you have all the information you need.

Or is it not reproducing when compiled debug? (uninitialized variables, yay)

- Frank

[Max Stats]

BTW, does anyone know if simply replacing "assert(o_ptr->kind);" with "if (!o_ptr->kind) return FALSE;" would be a viable fix? I know that this means that there is an invalid object or two (or more) floating around (it actually looks like an object that gets allocated but its structure never gets filled because all the flags are zero). I made this change but haven't really tested it yet, and there is no telling how long it takes for the bug to recur for testing. I just wondered if anyone already knew what the effect of this would be, if these objects are allowed to continue to exist instead of bailing with the failed assertion. There is explicit testing in the loading routines that doesn't place objects with no kind, so I am assuming that is why the bug doesn't persist when you reload the panic save that results.

[Starhawk]

Just my two cents, I'm playing this nightly:

23 Jun 2011 at 23:08 UTC, revision 431faa7

And I have had this error twice, both times when killing a cutpurse. Hope that helps.

edit: and if it matters, i'm on Windows XP.

[Max Stats]

I had assumed that it was triggered by an invalid object in the monster drop, but I'm almost certain I recall it happening in town after killing an Aimless-looking Merchant (which drops only gold). However, I'm only almost certain. But it might be worth looking into gold drops rather than object drops, just in case, since Cutpurses are also frequent gold-droppers.

Side note: The monster recall for the Cutpurse says it can carry up to seven objects or treasures! Is this right? That's a lot of drops, and maybe the reason why the previous poster encountered the bug with Cutpurses is that they generate more opportunities for the bug to hit.

[Derakon]

If it's a problem with dropping money, then it should be comparatively easy to trigger by rolling up a wizard and killing hydras.

The cutpurse's max drop might be influenced by its ability to pick up items. I know some *bands have had buggy monster memory because the character sees e.g. a poltergeist drop the entire contents of a vault. I haven't checked to see if Vanilla has the same problem though. Ideally the number in the monster memory should reflect the number of items the monster can have in inventory when it is generated.

[CunningGabe]

The cutpurse and aimless merchant can also both take items off the ground. Maybe that's the problem somehow.

[Max Stats]

I do notice that in obj-make.c make_object has a test for null kind but make_gold does not. I will do the hydra test and see what happens. Problem is, this bug seems to only appear when you aren't trying to make it appear.

[Max Stats]

I put in a test for null kind in make_gold and added a message that would announce that it had happened. Played awhile, got the bug again, but never saw the message. Maybe the gold route isn't it. Now I've added a similar test and message to make_object, including the monster index (if any) for which the object was created. Hoping that this will give me a heads up when the object is created (which should be when the monster is created) and I can watch for the monster that will be carrying it. If I get the bug without seeing either message, I don't know what that will mean.

EDIT: The bug happened for me on a master thief. Don't know if there is any connection to the previous poster's Cutpurse experience.

[CunningGabe]

I'm getting close. The problem seems to be with compacting objects and monster inventories. I don't have time to track it down completely right now, but it seems that after compact_objects(0) is called, then some monsters are left with references to dead objects. Maybe there's a fencepost error somewhere, so that everything in monster inventory except for one object is updated correctly?

[Derakon]

I'd guess it has something to do with monsters that pick up objects, personally. So perhaps objects that have been dropped are eligible for compacting even if they're currently in monster inventories?

[Nomad]

I'd guess it has something to do with monsters that pick up objects, personally.

Ah! I can definitely confirm that the storm giant that triggered the crash in that screencap I posted had picked up off a great hammer from the ground, because I remember being irritated that it had done it both the first time and when I replayed the level from my save.

I also got the crash fighting a group of black puddings in a corridor. Which I would recommend as possibly your best chance of reproducing it, since you end up with big piles of objects picked up and dropped.

I know nothing of how the code works, but is it possible the monsters are picking up objects between the player auto-dropping them because they've been marked as squelch and the squelch actually happening?

[Max Stats]

I'm getting close. The problem seems to be with compacting objects and monster inventories. I don't have time to track it down completely right now, but it seems that after compact_objects(0) is called, then some monsters are left with references to dead objects. Maybe there's a fencepost error somewhere, so that everything in monster inventory except for one object is updated correctly?

The bug is frequently triggered with more than one object. For awhile, I had inserted code printing a message every time a null kind was encountered and attempting to continue, and sometimes I remember seeing three messages (always one after the other immediately upon monster death).

I was surprised to find that Angband still compacted objects. I thought this was a relic from the old days of computers with much more limited memory and processor speed. I know there still has to be a theoretical maximum, I just assumed that it could be set high enough that it would never be reached except in extreme circumstances.

I am also curious that I didn't see the "Compacting objects..." message before this bug. In fact, I don't recall ever seeing this message in recent times. That being said, this theory makes a lot of sense, given that make_object seems pretty robust about not creating objects will null kind, and the bug normally takes a long time to manifest. I guess the best way to go is to drastically lower the threshold for compacting objects and create lots of monsters that steal/pick up objects.