Bug: Crash happening upon monster death

[Max Stats]

This bug was being discussed in the 3.3.0 release thread and it has happened to me a few times. Basically, occasionally when you land the killing blow on a monster, the game will crash. It manages to write a save file, after which you can continue the game with the monster you just killed being at 0 HP, so you can kill it again immediately and proceed normally. The problem is, this means that you cannot capture the bug in a save file, unless you know the bug is about to happen and save immediately before.

If the game is run from the command line, you can see the error text, which is: "angband: object/identify.c:132: object_flavor_is_aware: Assertion `o_ptr->kind' failed." By putting in some debugging code, I managed to figure out that the routine that was calling object_flavor_is_aware before the crash was squelch_item_ok.

So if I understand correctly, this may be triggered when a monster's drops are tested for being squelched to determine if they should be shown. I don't know the flow of the code well enough to look deeper.

[d_m]

So if I understand correctly, this may be triggered when a monster's drops are tested for being squelched to determine if they should be shown. I don't know the flow of the code well enough to look deeper.

You understand correctly

I have found one path that *may* cause this and have a fix I haven't tested. I haven't reproduced this yet (played for a few hours under GDB hoping to hit it) but my theory is that it's a special artifact being improperly generated, which is why it's (relatively) rare.

More info as I discover it.

[Magnate]

You understand correctly

I have found one path that *may* cause this and have a fix I haven't tested. I haven't reproduced this yet (played for a few hours under GDB hoping to hit it) but my theory is that it's a special artifact being improperly generated, which is why it's (relatively) rare.

More info as I discover it.

I'd be surprised if it was to do with special artifacts (though I am not disputing the problem you have uncovered in that code path). Max says that the crash is called from squelch_item_ok, and artifacts are never squelched. Besides, the monster is already carrying the drop before it is killed, so if the problem was with an item being carried having null kind, the crash would reproduce every time the monster is killed.

The key is that the crash is not reproducible after reloading and re-killing the monster. So it can't be anything to do with the actual item, since it drops perfectly on the reload. Makes me wonder if it's a memory leak.

[Max Stats]

I had the bug hit again earlier tonight, but this time it was called from map_info. I wonder if I walked over an illegal item? But again, the crash was gone when I reloaded.

EDIT: Correction. This was because I added another layer of debug code, so map_info was what called squelch_item_ok, which in turn called object_flavor_is_aware.

[Jazerus]

You understand correctly

I have found one path that *may* cause this and have a fix I haven't tested. I haven't reproduced this yet (played for a few hours under GDB hoping to hit it) but my theory is that it's a special artifact being improperly generated, which is why it's (relatively) rare.

More info as I discover it.

It could be the Phial. I haven't found it in 3.3.0 RC at all across multiple games, and it would fit with Smeagol causing the crash.

[Max Stats]

It could be the Phial. I haven't found it in 3.3.0 RC at all across multiple games, and it would fit with Smeagol causing the crash.

The Phial might be one cause, but it is definitely not the only one. I have encountered the bug after finding the Phial, in fact after finding both the Phial and the Star.

[Nomad]

Just got this myself in the June 22 nightly:



No panic save, alas, but this was on dlevel 44, randarts game, and I hadn't found any special artefacts yet.

[d_m]

I think the next RC that Magnate pushes may fix this. We'll have to see...

[Max Stats]

Oops! Still there, as of latest release (v3.2.0-1087-g9367950-dirtybash-4.1). I'll try to put my debugging code back in and snare this bug again.

[Max Stats]

What would cause an object to be generated with tval and sval of zero? An object with these values triggers the bug.

[d_m]

What would cause an object to be generated with tval and sval of zero? An object with these values triggers the bug.

The short answer is we're not sure... or else we'd be trying to stop that thing happening

There are some possible explanations, although I'm kind of just throwing things out:

1. Object creation fails in a way that doesn't signal that the item is bogus, and it gets put into the dungeon/monster inventory.

2. Some kind of stack merge fails and leaves a cleared empty object lying around

3. Objects on floor or in monster inventories are stored in a linked list... could be buggy list handling code somewhere

4. Some kind of incomplete item destruction

As I say, these are vague descriptions, and it may be something else entirely.

[Max Stats]

This bug is getting to be more and more inscrutable all the time. I thought I would add a line to mon_take_hit to write out a savefile (to a different location than my regular savefile) every time I damaged a monster. I was hoping that this way when the bug hit I would actually have a save from right before the monster in question was killed. However, when the bug eventually hit and I loaded this save file, the bug did not repeat itself. This is despite the fact that the monster still had health in the health bar, so the moment of saving should have been before the game considered the monster dead and dropped its objects. So now I wonder if this is some sort of in-game corruption that happens over a period of playing, but is eliminated after reloading?

Since the bug is persisting, I opened a ticket for it.

On a side note, to make the interim savefile code work, I had to tweak savefile_save because it uses the path you provide in order to create the ".new" and ".old" temp files, but then uses the default savefile name when moving the temp file back to the real savefile. This doesn't seem like intended behavior but hadn't been an issue because the game always saves to the default location. All it required was replacing 'savefile' with 'path' in the calls to file_move.

[d_m]

Hey Max,

Are you able to reproduce this bug easily?

If so I may send you some custom EXEs to try out. I have still never been able to see it yet.

[Max Stats]

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.

Since I managed to figure out that the bug comes from map_info, and there is only one place where map_info calls squelch_item_ok (which in turn calls object_flavor_is_aware), I have inserted a test: if (!o_ptr->kind) continue; before the call (will probably add a message in there so I can see that it has happened as well), so I'll see if this fixes it without causing any new problems.

[Napsterbater]

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