frustrating crash bug

[takkaria]

To get rid of the snprintf() error, switch to using strnfmt() instead. VC++ doesn't support snprintf() and strnfmt() is what angband uses instead everywhere else.

[will_asher]

I got it built in V++! I started over making sure not to select CLR empty project, as you suggested and it got rid of all the errors except the snprintf one, and I replaced that with strnfmt(). (The snprintf() was in a piece of Eddie's code) When I started the project the first time, I didn't know what CLR meant and thought it might just be 'clear empty project'.

Anyway, I ran it and it crashed again after I took less than 10 steps from the stairs where I started. V++ pointed me to the distance() function. hmmm, is it bad if one of the 'x' values is negative?

I think I've narrowed it down to my get_random_des() function in melee2.c

[PaulBlay]

Anyway, I ran it and it crashed again after I took less than 10 steps from the stairs where I started. V++ pointed me to the distance() function. hmmm, is it bad if one of the 'x' values is negative?

That's very odd, because it won't crash for me.

Did you use the files.c and dungeon.c source files that I emailed you? That's the only difference I can think of off hand. (Although I can't see how they could be involved)

As for the 'distance' function, it should never return a negative. It also seems unlikely (but not impossible, I suppose) that that any of x1, y1, x2 and y2 should be negative.

				y = rand_spread(dy, dis);
				x = rand_spread(dx, dis);
				d = distance(dy, dx, y, x);

[EDIT] OK, I take that back. Given the above code it is quite likely for y2 or x2 to be negative.

[PaulBlay]

You could do this if you want to be cautious.

			/* Pick a (legal) location */
			while (1)
			{
				y = rand_spread(dy, dis);
				x = rand_spread(dx, dis);
				/* Ignore illegal locations */
				if (!in_bounds_fully(y, x)) continue;
				d = distance(dy, dx, y, x);
				if ((d >= min) && (d <= dis)) break;
			}

but, like I said, it didn't crash for me before then.

[will_asher]

Did you try going into the dungeon and coming back to town? If it has to do with my get_random_des() function, then it wouldn't crash unless a roaming monster was generated (one that's awake before noticing the player). Then again, if it has to do with that function I don't understand why it only crashes in town.

[PaulBlay]

Did you try going into the dungeon and coming back to town?

Yes.

If it has to do with my get_random_des() function, then it wouldn't crash unless a roaming monster was generated (one that's awake before noticing the player). Then again, if it has to do with that function I don't understand why it only crashes in town.

Stick a break point at the start and end of get_random_des() and skip through it a few times with F5. If it crashes half way through then it probably is get_random_des. (Although I guess you've probably already got that far?)

[will_asher]

It crashed inside get_random_des().

What does this mean?:
The thread 'Win32 Thread' (0x17cc) has exited with code 0 (0x0).

[PaulBlay]

It crashed inside get_random_des().

What does this mean?:
The thread 'Win32 Thread' (0x17cc) has exited with code 0 (0x0).

Well, frankly it's not much help as messages go.

What I suggest you try now is to narrow down where in get_random_des it crashes. You could do that by either stepping through with F11 or by adding / moving breakpoints.

[Atarlost]

You know, being level 0 isn't the only thing unique about the town. It's also the only small level. You may be making assumptions about dungeon size somewhere in your monster roaming code.

[PaulBlay]

It's also the only small level.

Good point. Actually I think I mentioned in a completely unrelated thread that the in_bounds_fully macro should check against TOWN_WID and TOWN_HGT not DUNGEON_WID and DUNGEON_HGT when on dlvl 0.

[will_asher]

Hooray!! I added a define for in_town_fully, and changed this

			/* Ignore illegal locations */
			if (!in_bounds_fully(y, x)) continue;

to this

			/* Ignore illegal locations */
			if ((p_ptr->depth) && (!in_bounds_fully(y, x))) continue;
			else if (!in_town_fully(y, x)) continue;

and I can't get it to crash again. I hope that means that the crash bug is fixed. I still wonder why it crashed for me but not for Paul. DaJAngband 1.0.98 should be released very soon (..unless I was wrong about this one being fixed or I find another serious bug that I can't figure out).

Thanks for the help!

[Pete Mack]

Which brings us to the question: why are there two macros where one will serve?

#define in_bounds_fully(y,x) \
(p_ptr->depth == 0 ? .... )

[will_asher]

Which brings us to the question: why are there two macros where one will serve?

#define in_bounds_fully(y,x) \
(p_ptr->depth == 0 ? .... )

I don't know how to finish that sentance. The only reason I could make a 'in_town_fully' is because there was already a similar 'in_bounds_fully' to copy from and replace DUNGEON with TOWN.
I do a lot of things that way actually. I wouldn't know how to do it from scratch without help, so I just copy it from something similar and tweak it.
The monster roaming code choses a random destination for the monster to go towards using stuff copied from the teleportaiton code.

[Pete Mack]

#define in_bounds_fully(Y,X) \
( (Y) > 0) && (X) > 0) && ( p_ptr->depth != 0 ? \
((Y) < DUNGEON_HGT-1) && ((X) < DUNGEON_WID-1) \
: ((Y) < TOWN_HGT-1) && ((X) < TOWN_WID -1) ) )


EDIT: Cut and paste errors fixed

[will_asher]

I did that and it gives me an error saying "missing ";" before '&&'" and points to the lines where in_bounds_fully is referenced.