Random Indexes of Memory get Cleared about assemblyscript HOT 3 CLOSED

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

from assemblyscript.

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

from assemblyscript.

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!

from assemblyscript.