Help me make my new variant! (please!)

[will_asher]

No, randint is a pure function--that is, it can never corrupt memory. It is arrays and strings that are usually the problem.

Could it be a string that's too long? How do I know how long a string can be?

[Julian]

Trying to randint0() zero or a negative number wouldn't cause memory issues, would it?
(I'm guessing that would be a different kind of problem.)

It can’t cause a problem at all; it’ll just give you 0 if you call it on anything <= 0

[Pete Mack]

No, randint is a pure function--that is, it can never corrupt memory. It is arrays and strings that are usually the problem.

[will_asher]

...still working on this same problem...
Trying to randint0() zero or a negative number wouldn't cause memory issues, would it?
(I'm guessing that would be a different kind of problem.)

I would think bugs would be easier to find when I have a diff of those changes to look at, but I put several changes in one commit. (I'll have to avoid doing that in the future...)

[Julian]

The real problem here is that Angband is written in C, and C is a terrible language made entirely of sharp edges.

In particular, it makes you manage memory yourself, and if you screw up, it just sets seemingly-random bits of the program on fire at runtime.

You'€™re probably going to be happier if you take a little time to learn some C separately, rather than trying to learn it on the fly in the middle of a somewhat complicated codebase.

(I don’t have any recommendations; the way I learned C many moons ago is not advisable for people without a programming background. (And not really advised for those who do.))

[will_asher]

I can't think of anything I did in the code off hand that could likely have caused that kind of problem, but this helps me have an idea what to look for.
(I won't have much chance to work on it in the next couple days though.)

[Nick]

an s16b can be negative right?

Yes, that's right.

Is there a limit to how many variables are saved in a struct?

No, the size in memory of a struct will be as big as it needs to be to hold all the variables. If you have a fixed length array in a struct, that's accounted for too. If you have a pointer which is to be used as an array, then the array needs to be allocated before it can be used; for example, the player struct gets initialised when the game starts in the init_player() function, which allocates all the necessary arrays:

static void init_player(void) {
	/* Create the player array, initialised with 0 */
	player = mem_zalloc(sizeof *player);

	/* Allocate player sub-structs */
	player->upkeep = mem_zalloc(sizeof(struct player_upkeep));
	player->upkeep->inven = mem_zalloc((z_info->pack_size + 1) * sizeof(struct object *));
	player->upkeep->quiver = mem_zalloc(z_info->quiver_size * sizeof(struct object *));
	player->timed = mem_zalloc(TMD_MAX * sizeof(s16b));
	player->obj_k = object_new();
	player->obj_k->brands = mem_zalloc(z_info->brand_max * sizeof(bool));
	player->obj_k->slays = mem_zalloc(z_info->slay_max * sizeof(bool));
	player->obj_k->curses = mem_zalloc(z_info->curse_max *
									   sizeof(struct curse_data));

	options_init_defaults(&player->opts);
}

[will_asher]

The general idea is that you're accessing a bit of memory that you're not meant to. A common one is using a bad array index - too long, or accidentally negative.

Thanks, that gives me some idea what to look for.
an s16b can be negative right?
Is there a limit to how many variables are saved in a struct?

[Nick]

What other kinds of things might cause the memory issues?

The general idea is that you're accessing a bit of memory that you're not meant to. A common one is using a bad array index - too long, or accidentally negative.

[Pete Mack]

@will--
It's impossible to guess what went wrong, beyond the basic knowledge of a memory error. You need a diff of the code compared to the original. However, you can be sure the error isn't in the save/load code, because you are starting from a clean install with no existing character.

[will_asher]

That doesn't look like it would lead to memory issues in itself, but after the change it probably wouldn't load old savefiles correctly, which could conceivably have led to your problems.

What other kinds of things might cause the memory issues?

[will_asher]

That doesn't look like it would lead to memory issues in itself, but after the change it probably wouldn't load old savefiles correctly, which could conceivably have led to your problems. Have you tried with a fresh savefile?

yes

(Adding a little blah blah because the forum won't let me post a 3-character reply.)

[Nick]

here's what I did.

That doesn't look like it would lead to memory issues in itself, but after the change it probably wouldn't load old savefiles correctly, which could conceivably have led to your problems. Have you tried with a fresh savefile?

[will_asher]

here's what I did. I added some things to the player struct in player.h like so

"
s16b p_luck; /* Luck */
s16b slimed; /* slime level */
<a few more similar ones, all of them are s16bs>
"
then I added them to save.c and load.c like so
"
wr_s16b(player->p_luck); /* luck */
wr_s16b(player->slimed); /* slime */
...
"
"
rd_s16b(&player->p_luck);
rd_s16b(&player->slimed);
...
"

oh and save.c had this "
wr_s16b(0);
wr_s16b(0);
wr_s16b(0);
wr_byte(0);
"
in that spot before with a corresponding
"
strip_bytes(7);
"
in load.c.
I figured I didn't need that stuff and cut it out.
hmmm...
So just now I put those empty s16bs and the strip_bytes() line back in and ...it didn't make any difference. thought it was worth a try.

Anyway, that's all I did to the savefiles.
EDIT: and I don't know what "dynamic allocation" is. I didn't change anything that looked like it allocated or released anything.

[backwardsEric]

How do I know if it's writing beyond the boundaries of an array?
and How do I know what the boundaries are?

There's tools to help detect them. I don't know what's best or readily available for your environment (Windows + Visual Studio). Electric Fence, https://en.wikipedia.org/wiki/Electric_Fence , is one fairly generic one for C. Like many of those tools, it's likely best used in conjunction with a source debugger that will let you set breakpoints and query the call stack and contents of memory.

As for the second question, the boundaries are set when the memory allocation happened - with the size that was passed to the allocator.

Besides finding a tool to help detect the source of the memory corruption, manually reviewing your changes, while time-consuming, will likely help. Did the parts you added to the player structure involve dynamic allocation (likely if they are pointers)? If so, check that the size specified for allocation is the right one. Try to identify the lifetime of what was allocated - when is it allocated and when is it released. Are there attempts to access it after it is released (either for reading, writing, or to release it again)? If so, that would be a problem. If you didn't add anything that required dynamic allocation, you would want to check your changes to the savefile loading. Are the loads of the right size and not overflowing the destination memory?