Bugs and complaints on current master

[Pete Mack]

Getting crashes on loading saved game--fails when scanning loaded trap data, which appears hopelessly corrupt.

[Nick]

I'm not sure what happened here....I was playing this character (yesterday) on one mac, moved the save file from the angband save file to my dropbox to play while I traveled, but opening the save file crashes angband.

Any thoughts?

Thanks, that was a considerable (if easily fixed) bug in saving and loading of traps, which would have occurred any time you saved and reloaded twice on the same level.

Attached is a fixed savefile - it is not quite as you saw it last, every trap on the current level is a pit...

I have pushed a build which fixes this problem, it should be up on the nightlies page before too long.

[Pete Mack]

Another crash from verbose mode object drop code:
[New Thread 8384.0x26a0]

Program received signal SIGSEGV, Segmentation fault.
object_is_ignored (obj=0x31fa494) at obj-ignore.c:584
584 if (obj->known->notice & OBJ_NOTICE_IGNORE)
(gdb) where
#0 object_is_ignored (obj=0x31fa494) at obj-ignore.c:584
#1 0x00459b3a in drop_near (c=0x32514a4, dropped=dropped@entry=0xb0f05c,
chance=chance@entry=0, y=57, x=139, verbose=verbose@entry=true)
at obj-pile.c:957
#2 0x0043c832 in monster_death (mon=mon@entry=0x7aafda8,

It is (again) dereferencing **dropped when that is already deleted/merged.

[Nick]

Another crash from verbose mode object drop code:
[New Thread 8384.0x26a0]

Program received signal SIGSEGV, Segmentation fault.
object_is_ignored (obj=0x31fa494) at obj-ignore.c:584
584 if (obj->known->notice & OBJ_NOTICE_IGNORE)
(gdb) where
#0 object_is_ignored (obj=0x31fa494) at obj-ignore.c:584
#1 0x00459b3a in drop_near (c=0x32514a4, dropped=dropped@entry=0xb0f05c,
chance=chance@entry=0, y=57, x=139, verbose=verbose@entry=true)
at obj-pile.c:957
#2 0x0043c832 in monster_death (mon=mon@entry=0x7aafda8,

It is (again) dereferencing **dropped when that is already deleted/merged.

Hm. Looks like *dropped was probably OK but (*dropped)->known was probably already freed.

Do you know what the monster was - a mimic maybe?

[Pete Mack]

Uh oh. Mystery free memory access:

warning: HEAP: Free Heap block 07B47D00 modified at 07B47D28 after it was freed

where
#0 0x778d06f8 in ?? ()
#1 0x77835c95 in ?? ()
#2 0x77835b32 in ?? ()
#3 0x778cf136 in ?? ()
#4 0x778381c6 in ?? ()
#5 0x77835c95 in ?? ()
#6 0x77835b32 in ?? ()
#7 0x74bc79b0 in msvcrt!malloc () from C:\WINDOWS\SysWoW64\msvcrt.dll
#8 0x004b554b in mem_alloc (len=len@entry=196) at z-virt.c:41
#9 0x004b55b1 in mem_zalloc (len=196) at z-virt.c:54
#10 0x0049380d in display_map (cy=cy@entry=0x0, cx=cx@entry=0x0)
at ui-map.c:656
#11 0x00487b8c in update_minimap_subwindow (type=EVENT_END, data=0x0,
user=0x5313d0 <minimap_data+48>) at ui-display.c:1683
#12 0x00414469 in game_event_dispatch (data=0x0, type=EVENT_END)
at game-event.c:43
#13 event_signal (type=EVENT_END) at game-event.c:142
#14 0x0046ad17 in redraw_stuff (p=0x37) at player-calcs.c:2463
#15 0x004149a4 in process_player_cleanup () at game-world.c:597

[Pete Mack]

@Nick -- I'm 99% sure it was an Ogre.

[Nick]

OK. Looks like time for some memory checking.

[Pete Mack]

You can detect these errors by running in verbose mode with -g -O2 compiler flags. This forces the debug memory management and allows good stack traces, but it still runs plenty fast. I hit crashes about every 5 levels playing this way...and that's a good thing. Thanks for fixing the nightmarish trap bug on restore. Lost a save file completely to that.

[PowerWyrm]

OK. Looks like time for some memory checking.

obj->ego = &e_info[lookup_ego_item(buf, obj->tval, obj->sval)];

If lookup_ego_item() fails for any reason, it returns -1, which would do a memory access error. Would be better for lookup_ego_item() to return a struct ego_item * directly (NULL if the function fails).

Same goes for lookup_artifact_name().

[Nick]

obj->ego = &e_info[lookup_ego_item(buf, obj->tval, obj->sval)];

If lookup_ego_item() fails for any reason, it returns -1, which would do a memory access error. Would be better for lookup_ego_item() to return a struct ego_item * directly (NULL if the function fails).

Same goes for lookup_artifact_name().

That's a really good idea.

[StMicah]

thanks, Nick. Much appreciated!

[PowerWyrm]

New traps don't have tile mappings in the graf-XXX.prf files. I think this leaves them as a small ASCII symbol within a big black square.

[Nick]

New traps don't have tile mappings in the graf-XXX.prf files. I think this leaves them as a small ASCII symbol within a big black square.

Indeed, and one of the things I needed to do in the lead up to 4.1 was talk to the currently available tile artists about producing new tiles. Old ones could probably be re-purposed for traps, but it's possible there will be some new monsters

[Pete Mack]

@Nick---
How did you fix that crash from bad trap data? I hit it again. Apparently forgot to recompile after updating :/ Now I have a promising character lost, unless I can fix it.

[Nick]

@Nick---
How did you fix that crash from bad trap data? I hit it again. Apparently forgot to recompile after updating :/ Now I have a promising character lost, unless I can fix it.

I ran in gdb, put a break in rd_trap() in load.c at these lines:

	rd_string(buf, sizeof(buf));
	if (buf[0]) {

and then set buf="pit" (for every trap on the level...).