[ANNOUNCE] NPPAngband 6.1.1

[nppangband]

Very strange that the table is null at that point.


Actually, there is alot of things strange in the log (below).

#0  0x00000000004a4863 in get_obj_num (level=1) at object2.c:72
#1  0x00000000004aa2c4 in make_object (j_ptr=0x7fffffffcd70, good=0 '\000', 
    great=0 '\000', objecttype=0, interesting=0 '\000') at object2.c:3548
#2  0x00000000004aa9f1 in place_object (y=6, x=23, good=0 '\000', great=0 '\000', 
    droptype=0) at object2.c:3876
#3  0x00000000004567bc in alloc_object (set=2, typ=5, num=13) at generate.c:941
#4  0x0000000000466d13 in place_monsters_objects () at generate.c:9721
#5  0x000000000046a448 in cave_gen () at generate.c:11292
#6  0x000000000046b034 in generate_cave () at generate.c:11829
#7  0x00000000004420bc in play_game () at dungeon.c:3821
#8  0x0000000000523c56 in main (argc=1, argv=0x7fffffffde78) at main.c:437

First, the table has already been initialized (in init2.c, around line 1010). The game could never make it to the splashscreen in this didn't happen sucessfully.
Second, the table, and that specific function where the crash happens, has already been used to generate all the store inventory during player birth (birth.c, line 1345).

[AnonymousHero]

I see two "obvious" possiblities:

1. Maybe something is scribbling over memory. (Not unheard of in Angband-land.)
2. Maybe GCC is doing aggressive optimizations based on the code invoking undefined behavior.

Both of these are quite sensitive to the environment (compiler version, 32-bit/64-bit, etc.) in my experience, so they seem plausible.

[AnonymousHero]

Alright, so I've been breakpointing + tracing a little. It appears that alloc_kind_table is being set to NULL somewhere inside

update_mon_sidebar_list

On line 1902 of calcs.c it's still != NULL, but after line 1903 it is NULL. I'll investigate further when I get back from work.

Addendum: It's

C_WIPE(sidebar_monsters, SIDEBAR_MONSTER_MAX, sizeof(int));

which does the deed, so there's likely something wrong with sidebar_monsters or SIDEBAR_MONSTER_MAX.

[AnonymousHero]

Ah, got it, I think!

The C_WIPE line shouldn't say "sizeof(int)" it should just say "int". The C_WIPE macro does sizeof itself, and so we get

memset(..., sizeof(sizeof(int)));

On 32-bit sizeof(sizeof(int)) happens to be equal to sizeof(int), but it's not on 64-bit.

EDIT: Tested and that fixes it. I can create a pull request if you want, but it's probably easier if you just fix it yourself .

[nppangband]

Wow. Thank you. So even if I had installed arch-linux on my old 32-bit machine, I still wouldn't have found it.

I had been working some long hours but I do have the day off today, so I can catch up on all this and upload a new version.

[nppangband]

I checked all other instances of C_WIPE in the code. There are a couple more in init1.c that use sizeof inside a call of C_WIPE. See line 2325 of init1.c for an example. It looks like those should be changed as well. I wonder why those never caused a problem. It must be overwriting something.

[AnonymousHero]

Excellent. Happy to help .

[Nick]

Just noticed an amusing typo, from the current competition leader:

Killed by Lungorthin, the Balrog of White Fir.

All the other balrogs laugh at him because he likes trees.

[nppangband]

Fixed. I just needed to make the max length for a monster name a couple characters longer.

But I will never see Lungorthin again without laughing at him a little bit...