Bugs and complaints on current master

[Nick]

New build will be up shortly, hasn't fixed any existing bugs, probably introduces lots of new ones, and breaks current randart savefiles - so if you're in the middle of a randart game, don't update yet.

[kandrc]

Haven't had one of these in a while. In 4.0.3-633-g347dcad:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004deb97 in flag_on_dbg (flags=0x21 <Address 0x21 out of bounds>, size=3, flag=1, fi=0x4ec98d "c->squares[y][x].info", fl=0x4ec981 "SQUARE_MARK") at z-bitflag.c:226
226             if (flags[flag_offset] & flag_binary) return false;
(gdb) bt
#0  0x00000000004deb97 in flag_on_dbg (flags=0x21 <Address 0x21 out of bounds>, size=3, flag=1, fi=0x4ec98d "c->squares[y][x].info", fl=0x4ec981 "SQUARE_MARK")
    at z-bitflag.c:226
#1  0x00000000004099ad in square_mark (c=0xb48f48, y=0, x=53) at cave-square.c:1098
#2  0x0000000000405568 in wiz_light (c=0xb47208, full=false) at cave-map.c:446
#3  0x0000000000420d24 in labyrinth_gen (p=0x9c84c8) at gen-cave.c:887
#4  0x000000000041e341 in cave_generate (c=0x74b5a0 <cave>, p=0x9c84c8) at generate.c:864
#5  0x000000000041c4ca in run_game_loop () at game-world.c:840
#6  0x00000000004ae7cf in play_game (new_game=false) at ui-game.c:433
#7  0x00000000004e6b7d in main (argc=1, argv=0x7fffffffdc48) at main.c:524
(gdb)

EDIT: And just died because of it. Was reloaded in the level I was fleeing, invisible. I think that I was sharing a cell with a monster, but I may have been embedded in a wall. Phase and teleport didn't seem to do anything. Attempts to move all failed. Eventually I was killed.

I've actually had this problem before (and failed to report it). Game panic saves (I assume?) when it crashes while generating a new level. Fails to place the PC someplace reasonable (once I was placed inside permanent rock). If, for whatever reason, it's difficult to know where @ was, it should probably be placed on an open stair, even if that means creating a new one special just for that purpose.

[Nick]

Yes, I've seen that too - it's an issue with labyrinths, but I don't fully understand it yet.

[kandrc]

Here's another. Not a crash, but an infinite loop. Read an un-id'd scroll in town. Turned out to be create traps.

Program received signal SIGINT, Interrupt.
Rand_div (m=37) at z-rand.c:203
203                             if (r < m) break;
(gdb) bt
#0  Rand_div (m=37) at z-rand.c:203
#1  0x00000000004a0cb0 in pick_trap (feat=1, trap_level=0) at trap.c:185
#2  0x00000000004a0e7e in place_trap (c=0xc849b8, y=9, x=54, t_idx=-1, trap_level=0) at trap.c:238
#3  0x0000000000409059 in square_add_trap (c=0xc849b8, y=9, x=54) at cave-square.c:935
#4  0x0000000000492b32 in project_feature_handler_MAKE_TRAP (context=0x7fffffffb9d0) at project-feat.c:286
#5  0x000000000049373c in project_f (origin=..., r=1, y=9, x=54, dam=0, typ=31) at project-feat.c:694
#6  0x00000000004920f4 in project (origin=..., rad=1, y=9, x=54, dam=0, typ=31, flg=244, degrees_of_arc=0, diameter_of_source=0 '\000', obj=0xbeff88) at project.c:1008
#7  0x000000000041172d in project_touch (dam=0, typ=31, aware=false, obj=0xbeff88) at effects.c:158
#8  0x0000000000418c24 in effect_handler_TOUCH (context=0x7fffffffd910) at effects.c:3789
#9  0x000000000041a001 in effect_do (effect=0x8aed58, origin=..., obj=0xbeff88, ident=0x7fffffffd9f3, aware=false, dir=5, beam=0, boost=80) at effects.c:4487
#10 0x000000000040f95d in use_aux (cmd=0x74bed0 <cmd_queue+2288>, obj=0xbeff88, use=USE_SINGLE, snd=0) at cmd-obj.c:505
#11 0x000000000040fcbb in do_cmd_read_scroll (cmd=0x74bed0 <cmd_queue+2288>) at cmd-obj.c:602
#12 0x000000000040dabd in process_command (ctx=CMD_GAME, cmd=0x74bed0 <cmd_queue+2288>) at cmd-core.c:222
#13 0x000000000040dbb6 in cmdq_pop (c=CMD_GAME) at cmd-core.c:250
#14 0x000000000041bf3e in process_player () at game-world.c:666
#15 0x000000000041c1c9 in run_game_loop () at game-world.c:761
#16 0x00000000004ae7cf in play_game (new_game=false) at ui-game.c:433
#17 0x00000000004e6b7d in main (argc=1, argv=0x7fffffffdc48) at main.c:524
(gdb)

It looks like trap.c:195 is the issue:

  >|195                     if (kind->min_depth > trap_level) continue;

and we have:

(gdb) print trap_level
$6 = 0
(gdb) print *kind
$7 = {name = 0x87e568 "dart trap", text = 0x87e3d8 "A trap which shoots damaging darts.", desc = 0x87e758 "dexterity loss dart", msg = 0x0, 
  msg_good = 0x87e858 "A small dart barely misses you.", msg_bad = 0x87e668 "A small dart hits you!", msg_xtra = 0x0, next = 0x8822e8, tidx = 17, d_attr = 4 '\004', 
  d_char = 94 L'^', rarity = 0, min_depth = 6, max_num = 0, flags = "\022\004", save_flags = "\000\000\000\000", effect = 0x87e698, effect_xtra = 0x0}
(gdb)

If I set a breakpoint on pick_trap() and manually set trap_level to (arbitrarily) 10 each time, I'm able to get past it.

[PowerWyrm]

Yes, I've seen that too - it's an issue with labyrinths, but I don't fully understand it yet.

Clearly because of:

square_memorize(c, yy, xx);
square_mark([COLOR="Red"]cave[/COLOR], yy, xx);

"cave" and "c" are not identical, one is the new level (c), the other is the old one (cave) which doesn't exist anymore.

[PowerWyrm]

Here's another. Not a crash, but an infinite loop. Read an un-id'd scroll in town. Turned out to be create traps.

Create traps should be disabled in town anyway...

[Derakon]

How many of those "try infinitely until we find a match" loops are there in the game, anyway? Those seem like clear opportunities for bugs that lead to infinite loops. There should at least be a cap on how long we try for (like, 1000 attempts or something) and a graceful handling of failure.

[kandrc]

I've been frequently getting an error in which the save file is treated as if corrupt when the game fails to load an artifact for a dead character. The game aborts, forcing me to delete the save file and lose macros, inscriptions, etc. I haven't reported it before because I didn't want to dive into unknown code deeply enough to understand it. I decided to take a look this time.

My last game was randart (always randart). Load fails on the first call to lookup_artifact_name(), which fails to match the name of the randart. Peeking inside a_info[], I see that it's full of the standard artifacts.

In case it's apropos, I play with "use old set of randarts" false, and I literally never explicitly save or close the game; just keep it up on another virtual desktop.

This isn't a big deal when loading a dead file, but if the character were alive (don't know if this would occur then), it would be very annoying. Regardless, it might be beneficial to provide a fallback mechanism to keep settings while discarding the rest of the file, rather than simply aborting on any error.

Come to think of it, I'm pretty sure I've had this happen when loading an autosave after a crash. Not 100% certain on that, unfortunately.

[Nick]

I've been frequently getting an error in which the save file is treated as if corrupt when the game fails to load an artifact for a dead character. The game aborts, forcing me to delete the save file and lose macros, inscriptions, etc. I haven't reported it before because I didn't want to dive into unknown code deeply enough to understand it. I decided to take a look this time.

My last game was randart (always randart). Load fails on the first call to lookup_artifact_name(), which fails to match the name of the randart. Peeking inside a_info[], I see that it's full of the standard artifacts.

OK, thanks for that.

My plan to fix this is just not to save the dead player's gear and stores, which is where the problem seems to be arising. This should make reloading savefiles fairly robust; I will think about some more savefile restructuring to allow keeping setting on abort.

[PowerDiver]

OK, thanks for that.

My plan to fix this is just not to save the dead player's gear and stores, which is where the problem seems to be arising. This should make reloading savefiles fairly robust; I will think about some more savefile restructuring to allow keeping setting on abort.

I like saving those things. I believe that the choice to cheat death should be done the next time the game is started, when the emotions of YASD have worn off.

[Nick]

I like saving those things. I believe that the choice to cheat death should be done the next time the game is started, when the emotions of YASD have worn off.

Yes, I take your point. I'll do this for now, but may revisit it later.

[Nick]

Clearly because of:

square_memorize(c, yy, xx);
square_mark([COLOR="Red"]cave[/COLOR], yy, xx);

"cave" and "c" are not identical, one is the new level (c), the other is the old one (cave) which doesn't exist anymore.

Thank you, of course that's it. I'll have a look for others like that too.

[Nick]

New build is up, fixing

• Power levels of clairvoyance and enlightenment
• Hang on trap creation in town
• Crash on trying to create a lit labyrinth
• Error in update_mon()
• Savefile not loading for dead randart characters

I forgot to change the default for keeping the randart set, will do that soon.

Thanks to kandrc and PowerWyrm (and others) for these ones.

[Nick]

New build on the nightlies page, with a big change to how randarts are handled. If you have a current character with randarts DO NOT update; this should be the last time I have to say that, though.

Randarts are now written to an 'artifact.txt' file in the user directory, which is then automatically loaded. The old "keep randarts" option is now a "keep arts" option, and works as follows:

• if on, any existing 'artifact.txt' file in the user directory is used; in particular, if you just finished a randarts game, the same randarts will be used
• if off, any existing 'artifact.txt' file in the user directory is archived into an 'archive' directory inside the user directory (as artifact_1.txt, etc), and then randarts are generated or not according to the randarts option

IMHO this simplifies everything massively, but let me know if there are any problems with it.

[PowerWyrm]

Just a little memory leak: "msg" and "desc" from "struct obj_property" are not freed in cleanup_object_property().