Bugs and complaints on current master

[kandrc]

I hit the following (character was dead):

Program received signal SIGSEGV, Segmentation fault.
0x00000000004df521 in dice_reset (dice=0x7320707520666f20) at z-dice.c:165
165             dice->b = 0;
(gdb) print dice
$1 = (dice_t *) 0x7320707520666f20
(gdb) bt
#0  0x00000000004df521 in dice_reset (dice=0x7320707520666f20) at z-dice.c:165
#1  0x00000000004df6a2 in dice_free (dice=0x7320707520666f20) at z-dice.c:216
#2  0x00000000004197fd in free_effect (source=0x8864b8) at effects.c:4248
#3  0x000000000043337f in cleanup_curse () at init.c:1349
#4  0x00000000004800a2 in cleanup_parser (fp=0x7413a0 <curse_parser>)
    at parser.c:690
#5  0x000000000043d350 in cleanup_arrays () at init.c:5116
#6  0x000000000043d443 in cleanup_angband () at init.c:5203
#7  0x00000000004e6425 in main (argc=1, argv=0x7fffffffdc48) at main.c:538

This is in master with last commit tagged 76734a1717075a3cea7cdcb0326210967527d655.

[Nick]

I recall you use Linux? I think "./configure CLFAGS=-fsanitize=address LDFLAGS=-fsanitize=address [OTHER_OPTIONS]..." should work (if your compiler supports those, which I guess it does).
Although, I still don't know how Angband's build system works and just use makefiles
edit: (OTHER_OPTIONS are standard Angband's options, like --disable-curses, etc).

Thank you - I was having trouble getting the flags to work.

[t4nk]

In player-calcs.h, PR_INVEN and PR_MAP have exactly the same value:

#define PR_MAP			0x00010000L	/* Redraw whole map */
#define PR_INVEN		0x00010000L /* Display inven/equip */

All updates to inventory try to redraw the map, and vice versa.

[Nick]

In player-calcs.h, PR_INVEN and PR_MAP have exactly the same value:

#define PR_MAP			0x00010000L	/* Redraw whole map */
#define PR_INVEN		0x00010000L /* Display inven/equip */

All updates to inventory try to redraw the map, and vice versa.

Yeah, that's a bit embarrassing. Fixed in latest master.

[Ingwe Ingweron]

In latest nightly, when Sauron is killed, the stairs appear, but items that had fallen in the spot "disappear" according to the messages, rather than the items being shifted to a new spot on the floor.

[Nick]

In latest nightly, when Sauron is killed, the stairs appear, but items that had fallen in the spot "disappear" according to the messages, rather than the items being shifted to a new spot on the floor.

Right - that's a handy confirmation of my partial fix.

[AnonymousHero]

Debug builds set all values to 0xeeeeeeee in freed memory, and detects duplicate frees. It is a big win compared to, say, O2 for finding memory errors

Fair point, I suppose, but that's extremely dependent on platform and malloc implementation. (Which is valid, after all we are talking UB.). The sanitizers catch a much larger range of problems.

(Oh, and I believe the -O2 actually doesn't influence this, but rather -g. At least on GCC/Linux. However, I suppose it may cause optimizations which make the debug checks magically disappear.)

Anyway...

[Ingwe Ingweron]

Right - that's a handy confirmation of my partial fix.

Yeah, it still sucks a bit since Sauron's stairs destroyed a bunch of spent ammunition that would have been great to pick back up and use against Morgoth. C'est la vie.

[Nick]

Yeah, it still sucks a bit since Sauron's stairs destroyed a bunch of spent ammunition that would have been great to pick back up and use against Morgoth. C'est la vie.

What happens is the monsters drop falls to the ground in the usual way, then there is a check for S&M, which if passed builds the quest stairs, in the process pushing all the gear off the stair grid. It should just go to an adjacent grid unless they are all full - is it possible that there was nowhere to push the ammunition?

[Ingwe Ingweron]

What happens is the monsters drop falls to the ground in the usual way, then there is a check for S&M, which if passed builds the quest stairs, in the process pushing all the gear off the stair grid. It should just go to an adjacent grid unless they are all full - is it possible that there was nowhere to push the ammunition?

Well. there was somewhere the items could have been pushed. This is clearly a change that happened in the last few nightlies, as the previous behavior in the same circumstances would successfully push the items.

[t4nk]

Now that PR_INVEN doesn't redraw the map, I think PR_MAP should be added to effect_handler_MAP_AREA (effects.c). It even has a comment that says so...

	/* Redraw whole map, monster list */
	player->upkeep->redraw |= (PR_MONLIST | PR_ITEMLIST);

[PowerWyrm]

I'm just currently implementing the new rooms/dungeon levels for PWMAngband, and I've found a little glitch with early levels: sometimes, a "Moria" template is used, and since this template is based on the "Moria dwellers" pit template for monster generation (orcs + ogres + trolls + giants), the level is always generated empty. I think the template should not appear below a depth of 5, to at least see a couple snagas on the level.

[PowerWyrm]

Another problem with the new templates: Moria levels use mon_restrict() to set restriction on generated monsters, but doesn't call mon_restrict(NULL) afterwards like other templates (vaults, room of chambers). So if the next level is a classic level, it will still contain only orcs, trolls, ogres and giants (and a few hounds/canines which come as escorts).

In fact, there are cases in the gen-monster.c functions where mon_restrict(NULL) is not called when the generation fails.

[Nick]

Thanks for these, I should get to them soon.

[PowerWyrm]

Just got an endless loop in level generation. Tracked down the problem to the generation of an "Outside closets" room template, where the code fails to place monsters for the "9" tiles. Apparently, the code tries to place a monster on row 65, where cave height is 64 (the scatter() function should probably be adapted so that there's no endless loop if no location is available after some tries). Looking at the definition of the template in room_template.txt, it appears that the number of rows defined is incorrect: "rows:11" should be "rows:12".