Bugs and complaints on current master

[Nick]

No, this is before I get a chance to open a savefile, just opening the application.

OK, got it - it's the lore file. Here are my instructions from upthread:

The trick of copying monster.txt to lore.txt for full monster memory still works, or if you want to use your previous lore.txt you can go through and replace every line like this

name:22:large brown snake

with this

name:large brown snake

- so remove the numbers from the name: lines.

If anyone really wants to keep their old lore file and really doesn't want to do the number-removing trick, give me the file (email, or attach to forum or whatever) and I'll do it for you.

[Nick]

No, this is before I get a chance to open a savefile, just opening the application.

OK, thanks, I'll look into it.

[Azuria]

Is that with an existing savefile? Because it does break savefiles...

No, this is before I get a chance to open a savefile, just opening the application.

[Nick]

b11b07a is crashing on load again for Yosemite

Is that with an existing savefile? Because it does break savefiles...

[Azuria]

b11b07a is crashing on load again for Yosemite

[Nick]

New build up on the nightlies page with the most recent crash bug fixed, and savefiles broken really thoroughly, even by my standards.

This latest round of savefile breakages has been due to updates in the way the text files in lib/gamedata work. There may be a bit more of this still to happen, but the aim is to get as much info into the text files as possible, and then make savefiles as robust as possible against new records (monster, objects, etc) being added to the text files.

This has never happened to me before. I descended into an empty room with no other exit than the stairs I used to get down. Layout makes me assume that there should be a door in the end of the corridor. None to be found though.

Yeah - there's a template room at the end of the corridor, and it looks like the dungeon code has failed to tunnel into it. This may be due to one of the new dungeon generation algorithms in use; in any case, I've filed it as a bug.

[spara]

This has never happened to me before. I descended into an empty room with no other exit than the stairs I used to get down. Layout makes me assume that there should be a door in the end of the corridor. None to be found though.


Save: dead_end.zip

[Nick]

Just FTR, I'm still getting the heap-overflow sanitizer error whenever I dump randarts. (I think I already posted a stack trace, hopefully it's still reasonably applicable post-refactor. Let me know if you need a new stack trace.)

I can replicate the behaviour, but am completely mystified as to the cause. My best guess currently is that it's something to do with vstrnfmt not liking textblocks, possibly to do with text being written at the edge of a resizing of textblocks.

Any help on this would be most welcome. Clues include the fact that the error occurs in this bit of vstrnfmt:

					/* XXX There is a big bug here: if one
					 * passes "%.0s" to strnfmt, then really we
					 * should not dereference the arg at all.
					 * But it does.  See bug #666.
					 */

					/* Get the next argument */
					arg = va_arg(vp, const wchar_t *);

					/* Hack -- convert NULL to EMPTY */
					if (!arg) arg = L"";

					/* Prevent buffer overflows and convert string to char */
					/* this really should use a wcstombs type function */
					len = wcslen(arg);
					if (len >= 768) {
						len = 767;
					}
					for (i = 0; i < len; ++i) {
						arg2[i] = (char)arg[i];
					}
					arg2[len] = '\0';

which was changed in this commit and references this bug.

[AnonymousHero]

Just FTR, I'm still getting the heap-overflow sanitizer error whenever I dump randarts. (I think I already posted a stack trace, hopefully it's still reasonably applicable post-refactor. Let me know if you need a new stack trace.)

[Nick]

Here's a new one with your recent commits (4.0.3-590-g68835d3)

Excellent, thanks.

[kandrc]

Here's a new one with your recent commits (4.0.3-590-g68835d3):

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6e7fd1a in __strcmp_sse42 () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6e7fd1a in __strcmp_sse42 () from /lib64/libc.so.6
#1  0x0000000000426c2f in lookup_pit_profile (name=0x4f3968 "Moria dwellers")
    at gen-monster.c:53
#2  0x000000000042707c in mon_restrict (
    monster_type=0x4f3968 "Moria dwellers", depth=18, unique_ok=true)
    at gen-monster.c:166
#3  0x000000000042407a in moria_gen (p=0x9b97a8) at gen-cave.c:2053
#4  0x000000000041e2cd in cave_generate (c=0x74be20 <cave>, p=0x9b97a8)
    at generate.c:864
#5  0x000000000041c456 in run_game_loop () at game-world.c:840
#6  0x00000000004ae6d7 in play_game (new_game=false) at ui-game.c:433
#7  0x00000000004e6a55 in main (argc=1, argv=0x7fffffffdc48) at main.c:524
(gdb) up
#1  0x0000000000426c2f in lookup_pit_profile (name=0x4f3968 "Moria dwellers")
    at gen-monster.c:53
53                      if (streq(name, profile->name))
(gdb) print name
$1 = 0x4f3968 "Moria dwellers"
(gdb) print prof
prof_info              profil_counter         profil_counter_ushort  profile_max            
profil                 profil_counter_uint    profile                profile_parser         
(gdb) print profile
$2 = (struct pit_profile *) 0x98aa88
(gdb) print *profile
$3 = {next = 0x0, pit_idx = 0, name = 0x0, room_type = 0, ave = 0, rarity = 0, 
  obj_rarity = 0, flags = "\000\000\000\000\000\000\000\000\000", 
  forbidden_flags = "\000\000\000\000\000\000\000\000\000", 
  spell_flags = "\000\000\000\000\000\000\000\000\000\000", 
  forbidden_spell_flags = "\000\000\000\000\000\000\000\000\000\000", 
  bases = 0x0, colors = 0x0, forbidden_monsters = 0x0}
(gdb)

[Nick]

Another build up, and that should be the last of the savefile-breaking ones. Probably. And I wouldn't be surprised if there's the odd bug.

[Nick]

Nick--
Please don't do this. It's a pain when adding new monsters--messes up save files and lore in mysterious ways.

Sorry, already done

In the brave new world, monsters in both savefiles and lore will be completely identified by their names; I'm hoping this will actually make adding new monsters easier and safer (in fact, that's why I did it).

[Pete Mack]

Nick--
Please don't do this. It's a pain when adding new monsters--messes up save files and lore in mysterious ways.

Yes, sorry, I meant to post about that one (I was waiting for it to build, and got distracted).

36ded51 breaks savefiles, and also doesn't load previous lore.txt files any more. The trick of copying monster.txt to lore.txt for full monster memory still works, or if you want to use your previous lore.txt you can go through and replace every line like this

name:22:large brown snake

with this

name:large brown snake

- so remove the numbers from the name: lines.

EDIT: I should say, too, that there will be a bit of savefile breaking in the next few builds. I'm going through and removing the numbers from the name: lines in all the other text files (object.txt, artifact.txt, terrain.txt, etc) as well.

[Nick]

OK, nightlies page has a new build, which fixes at least two of those five problems (the ones that happened on failed trap disarms). The others all look likely to be memory corruption; I've run with sanitize on for a while and found nothing so far.

Note that this latest version also breaks savefiles (but not monster lore) again, and it won't be the last time.