[im3w1l]

It's may seem like a nitpick but I think it's a whole different way off looking at it to phrase it as "applying a bugfix that changed the order of allocations at startup exposed memory corruption somewhere else"

I do think there is something to be said for both perspectives, especially for code that is extremely critical. With sufficient testing and determinism maybe you can actually make sure that dormant issues stay dormant meaning there is real value in being change-averse. Still it's a very precarious situation having a known memory corruption hoping it's the testing has made sure its benign in practice.

[aidenn0]

IMO All it exposed was writing past the end of buffers.

There was no memory corruption previously due to partially to luck, and partially to heavy testing (which would have exposed most forms of memory corruption).

I think it is fare to say that the change was a cause of the vtable corruption occurring, since without the change it didn't happen.

Once this is discovered, you need to rethink your change plan for the next release; if you back out this one change, your software will return to a working state. Whether doing that, or fixing your buffer overflow is the correct thing to do depends on a lot of specific factors.