Help me make my new variant! (please!)

[Nick]

What does this mean? It sounds bad.
I added a couple things to savefiles in the player struct, but I thought I did it right...

It's hard to know for sure, but my starting point would be the savefile changes. Look at exactly what you've changed, and see whether the syntax matches existing code - for example, you may have done something like

rd_byte(tmp8u)

instead of

rd_byte(&tmp8u)

[will_asher]

thank you.

well.
I found almost that exact problem with the ampersands. So I fixed it, recompiled, and I'm still getting the same error popup...
(except the "at 0x..." number is different)

[Pete Mack]

Heap corruption means you borked the memory allocator, either with a write to freed memory, or with a buffer overrun. That particular error message suggests the debug allocator detected a buffer overrun, where you allocated insufficient space for a data structure. What does the stack look like at the time?

[will_asher]

Heap corruption means you borked the memory allocator, either with a write to freed memory, or with a buffer overrun. That particular error message suggests the debug allocator detected a buffer overrun, where you allocated insufficient space for a data structure. What does the stack look like at the time?

You're speaking a language I don't know here. What's a stack in this context? and where do I find it to see what it looks like?
(I know what borked means at least. I definitely borked something.)

[Pete Mack]

Eeek! The stack is the program's active memory-- when you subroutine gets called, it takes more space on the stack. Its memory is released when the routine exits. It also means the current set of subroutines that are active.
The heap is the program's long-term memory. It gets created and released in arbitrary order with malloc() (memory allocate) and free(). Each allocation has a fixed size, and if you write beyond it, your program eventually gets borked. There are two ways this commonly happens: writing beyond the boundaries of an array, and writing too long a string.

[will_asher]

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

When I first started making DaJAngband, I just discovered the txt files in the lib folder (the subfolder was called something other than gamedata at that point), and changed some things and added some new monsters. I posted about making changes in the txt files on here, and someone suggested I make my own variant. I said I can't do that I know only the barest basics of C, but they said something to the effect of Oh it isn't hard, you can probably figure a lot of things out by the comments. So I looked at the code, and the comments were so thorough in saying what the code was doing, that I could figure out how to customize a lot of stuff in the code. I'm a meddler, not a programmer, but I made my own variant before. I can do it again (with the help of the nice people here).

[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?

[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.

[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]

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.)

[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?

[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.

[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.

[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]

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);
}