bug - crash with tons of traps detected

[grinder]

Using revision d1db92e30511af698cc55b284693a5f928fca67a (with a savefile that was generated along different versions), I get a crash on loading the savefile (available on request). The game first crashed on using a rod of detection near a large vault.

Backtrace:

#0  0x002ef4ee in fread () from /lib/tls/i686/cmov/libc.so.6
#1  0x0818653d in file_read (f=0x825687c, buf=0xbffff3e0 "traps", n=28) at z-file.c:513
#2  0x080d7bf5 in try_load (f=0x825687c) at savefile.c:472
#3  0x080d7ec1 in savefile_load (path=0x8200760 "~/.angband/Angband-v4/save/1000.Username") at savefile.c:555
#4  0x08064bc6 in play_game () at dungeon.c:1621
#5  0x0818d73e in main (argc=1, argv=0xbffff574) at main.c:457

Let me take the opportunity to thank you for making Angband such great fun, having v4 in parallel is a terrific idea.

[CunningGabe]

Using revision d1db92e30511af698cc55b284693a5f928fca67a (with a savefile that was generated along different versions), I get a crash on loading the savefile (available on request). The game first crashed on using a rod of detection near a large vault.

Thank you for the report! Are you saying that the game crashed when you used the rod of detection, and now that savefile just crashes when you try to load it? Also, was the vault on the dungeon level that you started on right after updating to that revision?

[grinder]

Yes, it segfaulted while showing the "you detect traps" message. And yes, it segfaults on start, after pressing any key on the title screen (when save loading runs). Once, on a fluke, I was 'stepi'-ing in gdb around the crash point and the game was able to load, but crashed when I used an upstair.

As for whether the vault was created in latest revision, I believe I was playing with rev 81b526d8e4 (might be a bit earlier, sorry for imprecision), went down a stair, detected and got a crash. Then I updated to see if that would fix the crash, which didn't happen.

[CunningGabe]

Hmm. Well, why don't you post the savefile here and I'll take a look.

[grinder]

Thanks, here it is.

[CunningGabe]

Are you building from source? If so, can you make the following changes and recompile:

1. Add trap.txt to the Makefile in lib/edit.
2. Change line 36 of slay.c, replacing 257 with 513.

With those changes, I am able to load your savefile. It seems that the slay cache was running out of room, leading (I think) to an array index out of bounds.

[Magnate]

Are you building from source? If so, can you make the following changes and recompile:

1. Add trap.txt to the Makefile in lib/edit.
2. Change line 36 of slay.c, replacing 257 with 513.

With those changes, I am able to load your savefile. It seems that the slay cache was running out of room, leading (I think) to an array index out of bounds.

Oooh, that's extremely interesting - thanks for picking this up.

[grinder]

Thanks, Gabe.

I'm building from source, but with your changes it still crashes the same way (same backtrace on gdb).

I'm using a 32bit linux (ubuntu 10.04) and, since the crash happens in libc ("fread () from /lib/tls/i686/cmov/libc", see gdb output above), it might be hard to reproduce on other platforms.

[CunningGabe]

Thanks, Gabe.

I'm building from source, but with your changes it still crashes the same way (same backtrace on gdb).

I'm using a 32bit linux (ubuntu 10.04) and, since the crash happens in libc ("fread () from /lib/tls/i686/cmov/libc", see gdb output above), it might be hard to reproduce on other platforms.

Hmm. I'm puzzled. I can imagine that the new trap saving and loading code might be messed up in some subtle platform-dependent way, but I can't imagine how that would have caused the original crash when you used the rod of detection.

The only other guess I have is that it has something to do with displaying items on trap squares (though again, I haven't had problems with this on my end, using Windows 7). If you're up for a little detective work, you could try the following:

1. Do Ctrl-a, c, z, P to create a scroll of trap detection.
2. Read the scroll.
3. Drop a bunch of items (without moving).

If everything is working correctly, whenever an item drops onto a known trap square, it should show up as a red &.

[grinder]

Items on traps display fine. OTOH, using the debug mode to create a lvl50 character and teleporting to large-vault-depth gets crashy quick, sometimes even before detecting traps.

You say my save file works OK for you? Because I'm starting to suspect the crash could have led to an inconsistent save file 'traps' entry.

[CunningGabe]

Items on traps display fine. OTOH, using the debug mode to create a lvl50 character and teleporting to large-vault-depth gets crashy quick, sometimes even before detecting traps.

I was seeing the same thing -- but expanding the SLAY_CACHE_SIZE in slay.c seems to have fixed that for me. Maybe I'll try jumping around some more to make sure.

You say my save file works OK for you? Because I'm starting to suspect the crash could have led to an inconsistent save file 'traps' entry.

Yeah, you're probably right.

[grinder]

Yeah, you're probably right.

Today I ran under gdb to catch the crash: it seems to happen on saving/quitting besides a large vault, when freeing the traps in cave_free (cave.c:3642).

*** glibc detected *** /.../v4/src/angband: double free or corruption (!prev): 0x082a1e50 ***

[cut a bunch of stuff]

4  0x002fe161 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>, ptr=0x82a1e50)
    at malloc.c:6266
#5  0x002ff9b8 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4794
#6  0x00302a9d in *__GI___libc_free (mem=0x82a1e50) at malloc.c:3738
#7  0x0818c7a8 in mem_free (p=0x82a1e54) at z-virt.c:65
#8  0x08052f85 in cave_free (c=0x82a414c) at cave.c:3642
#9  0x080850e2 in cleanup_angband () at init2.c:3691
#10 0x0818d6f3 in main (argc=1, argv=0xbffff574) at main.c:460

I'll try to gather more useful info on this.

[grinder]

All I could gather was: saving and quitting from a dungeon level which has a high feeling (murderous or omens of death) results in a crash while freeing stuff, always in mem_free at z-virt.c.

mem_free was usually called from cave.c's cave_free (freeing traps, see backtrace above), sometimes in keymap_free at keymap.c and once in free_obj_alloc at object/obj-make.c.

The savefile gets corrupted somehow, leading to the crashes I posted about.

Edit: forgot to add that this was with latest (f7c33f8a9b) revision from git, which includes the slays cache fix. The character was created in this revision and I used debug mode to beef him up and teleport to around dl 97.

[CunningGabe]

Okay, _now_ I think I see the problem. In cave.c line 3625, I should be using tr_max instead of trap_max. The former is the max number of traps on a level, and the latter is the max number of trap kinds. So I was allocating only 30 or so spaces instead of the 1024 specified in limits.txt.

I'll fix that tonight and give the variables better names so I stop confusing myself.

[grinder]

In cave.c line 3625, I should be using tr_max instead of trap_max.

Wonderful, this fixes the crash when loading the original save for me (besides not crashing in debug mode tests). Thank you again, Gabe!