Rogue Aggravate() bug.

[Robert A. Monio]

In the recent posting of the rogue source a bug exists which causes a
core dump when you read a aggravate monster scroll. ("High Pitched
Humming Noise") I have not seen any postings from anyone concerning
this problem so I figured I would post this fix.

The problem exists in the file monster.c. The aggravate() routine
uses a while loop to "aggravate" the monsters on the level that the
player is currently on. While looping through the list of monsters on
that level, the pointer to the next monster is updated and the monster
is referenced before the pointer can be checked correctly. To fix
this problem, do the followng:

In monster.c, module aggravate()'s while loop looks like this in the
original posting :

while (monster) {
wake_up(monster);
monster->m_flags &= (~IMITATES);
monster = monster->next_monster;
if (rogue_can_see(monster->row, monster->col)) {
mvaddch(monster->row, monster->col, monster->m_char);
}

To correct the updating problem (and thus get rid of the core dump),
you should correct the block to look like this :

while (monster) {
wake_up(monster);
monster->m_flags &= (~IMITATES);
if (rogue_can_see(monster->row, monster->col)) {
mvaddch(monster->row, monster->col, monster->m_char);
monster = monster->next_monster;
}

Note that the monster pointer is now being updated after the if
block and that the null pointer will now be caught by the while loop.

I hope this helps anyone who has run into the same problem I have. For
anyone who is interested, I have this running on a NCR Tower XP
running SYS VR2 NCR Release 3.01. All of the previous patches (SYS V
updates and the fix to the unpack_armor routines) are installed. I've
encountered no other problems with this rogue source.

Good luck with this and Happy Hunting!

-Bob

--
Robert A. Monio UUCP: ihnp4!meccts!nis!pnessutt
Systems/Analyst - Technical Services ATT: (612) 894-9494
National Information Systems, Inc.
"These Proceedings are Closed!"

[Tim Stoehr]

In article <1...@nis.UUCP>, pnes...@nis.UUCP (Robert A. Monio) writes:
> The problem exists in the file monster.c. The aggravate() routine
> uses a while loop to "aggravate" the monsters on the level that the
> player is currently on. While looping through the list of monsters on
> that level, the pointer to the next monster is updated and the monster
> is referenced before the pointer can be checked correctly. To fix
> this problem, do the followng:

Yes, this bug was reported to me several months ago, and the fix posted.
Here, however, is a brand-new, never-before-seen bug that I just stumbled
upon today.

The code below is intended to ensure that party rooms have at least one
trap in them. However, I forgot about the possibility of party-mazes, and
there can be no trap inside of a maze, not even a party-maze. There was
also a '|' where there should have been a '&' Tsk, tsk. As a result, I
mysteriously teleported out of a party-maze. Rare, but it can happen.

In the file trap.c, in the routine add_traps(): you have:

do {
row = get_rand((rooms[party_room].top_row+1),
(rooms[party_room].bottom_row-1));
col = get_rand((rooms[party_room].left_col+1),
(rooms[party_room].right_col-1));
tries++;
} while ((dungeon[row][col] | (OBJECT | STAIRS | TRAP)) &&
(tries < 15));
if (dungeon[row][col] & (OBJECT | STAIRS | TRAP)) {
get_rand_row_col(&row, &col, (FLOOR | MONSTER));
}

Replace this with:

do {
row = get_rand((rooms[party_room].top_row+1),
(rooms[party_room].bottom_row-1));
col = get_rand((rooms[party_room].left_col+1),
(rooms[party_room].right_col-1));
tries++;
} while ((dungeon[row][col] & (OBJECT | STAIRS | TRAP | TUNNEL)) &&
(tries < 15));
if (dungeon[row][col] & (OBJECT | STAIRS | TRAP | TUNNEL)) {
get_rand_row_col(&row, &col, (FLOOR | MONSTER));
}