Random Indexes of Memory get Cleared

[torch2424]

Hello!

So I am not entirely sure if this is on my end or yours, even more unsure than #29 , but I'm really stumped on the issue.

So, If I noticed that pieces of memory I have in my wasm memory this.wasmByteMemory = new Uint8Array(this.wasmInstance.exports.memory.buffer), will get reset back to zero.

Like for example, if I'm expecting values in 0xF9A0, 0xF9A1, 0xF9A2, 0xF9A3. Everything will be fine in the game and then randomly, one of the indexes, 0xF9A0 will be cleared. And here's the scary part, I put listeners with a little wasm "consoleLog" I whipped up in front of all of my store<u8>() and store<u16>() calls, and nothing is written at the address, or near the address to clear the data back to zero.

After spending a few hours on this, and realizing I don't have a deep understanding of how wasm memory works, I thought it may be a variable overflowing into the memory buffer itself? It seems highly unlikely, and again it may be on my end. Sometimes it happens when an event happens in the game, and sometimes it doesn't 🤔

Anyways, if you need more context let me know, and thanks again for all of the help!

EDIT: I thought of more context, you can relate too haha! On tetris, whenever you clear a line, the side brick borders, will replace themself with a 0 zero tile. Like what's up with that? haha!

[dcodeIO]

Like for example, if I'm expecting values in 0xF9A0, 0xF9A1, 0xF9A2, 0xF9A3. Everything will be fine in the game and then randomly, one of the indexes, 0xF9A0 will be cleared

One thing that comes to my mind is that an adjacent unintended larger store could causes this, like for example the high 8 bits of a store<u16> also setting the 8 bits of the adjacent u8 to zero. If so, that could either be a compiler bug emitting the wrong-sized instruction, or (here) an actual store<u16> where it should be a store<u8>.

There's also this section in the cheat sheet, in case that helps. Basically, the type parameter states the size of the store (u8=1 byte affected, u16=2 bytes affected etc.) while the value operand's type is switched upon. The latter most likely isn't relevant here because it only decides for i32.storeX or i64.storeX, depending on if the value is a 64-bit integer, which wasmBoy doesn't seem to use.

From inspecting the .wast it appears that there's just a single store16 in wasm/memory/store/_sixteenBitStoreIntoWasmBoyMemory, while everything else is a store8. That matches the code so far. checkWriteTraps seems to be a likely candidate for where something could go wrong (isEightBitStore).

[dcodeIO]

Appears the game over screen also triggers quite a few heisenberg zeroes:

[torch2424]

Yeah exactly! I checked the sixteen bit stores with the same idea as you. But mostly, I was asking becuase I thought the wasn't itself could possibly overflow into it's own memory? But I guess not. If that is not the case, then I'll go ahead and close this, because I had a feeling it is something weird on my end haha! Thank you!