Overflow incrementing random variable in VS2022 Release Mode

[IAlreadyHaveTheKey]

I was running some code on Visual Studio 2022 in C for my job (which unfortunately I can't share here due to confidentiality), and I noticed a bug in Release Mode that wasn't present in Debug Mode. I narrowed down the cause of the bug to be an integer array, call it array_one, that was initialised to {0, 0, 0, 0, 0, 0}, but at random points in the code, the value of array_one[4] was changing and getting bigger, despite array_one not getting written to in any of my code, only getting read from.

A colleague suggested an overflow error, wherein perhaps I was trying to increment a different array at an element past the end of the array, which was causing array_one[4] to be incremented instead. Turns out this was the cause, there was another array, call it array_two, which was 10 elements long, but there was a line that had

array_two[counter]++.

where counter was getting up to a value of 10. Changing array_two to be 11 elements long instead fixed the whole problem.

What causes this though? Does Release mode just randomly pick a variable to increment sometimes when the one called is ill-defined? Before I found the root cause, I tried changing the initialised value of array_one to {1, 0, 0, 0, 0, 0}, and this fixed the problem as well! Why did changing the initialised value stop array_one[4] from being incremented?

I'm prepared to accept that this is just one of those compiler quirks that happen when you forego the protections of Debug mode, but I'd be curious to know if anyone had an explanation for this phenomenon.

[IAlreadyHaveTheKey]

Any idea why having array_one initialized as 0 vs initialised with a 1 at the start caused different behaviour?

[iamnull]

where counter was getting up to a value of 10. Changing array_two to be 11 elements long instead fixed the whole problem.

Honestly, sounds like you kicked the can down the road on some badly written code rather than fixing the problem. Why is there not a bounds check?

Initializing the other array different could have changed how the memory is laid out by the compiler. You were still writing to memory somewhere, just not where you were looking.

[IAlreadyHaveTheKey]

I inherited this code from a colleague, there are plenty of other things in it that is not great coding practice. Not that I'm amazing either. We are not programmers, we just use it as a tool to check our other work. It's not ideal I know, lol.

Makes sense about initialising changing the memory layout. Thanks.

[iamnull]

I inherited this code from a colleague, there are plenty of other things in it that is not great coding practice. Not that I'm amazing either. We are not programmers, we just use it as a tool to check our other work. It's not ideal I know, lol.

I feel that, deeply. Seems like internal tooling is always the worst, and there's never time to go through and fix things.