Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

cookieplmonster.github.io

Post reply on HN
Print view View original

221–230 of 315 posts

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#221

Post by dontlaugh »

Arainach wrote: post #215
foxhill wrote: post #168

Earlier quoted context omitted.

it probably shouldn’t be a “release” thing. actually, certainly. i do wonder how many bugs would never have seen the light of day, if someone’s “set” actually turned out to be a sequence (i.e. allowed duplicate values) resulting in a debug build raising an assert.

Debug builds are worthless for catching issues. How many people actually run them? Perhaps developers run debug builds of individual binaries they're working on when they're trying to repro a bug, but my experience at every company of every size and position in the stack (including the Windows team) is that no one does their general purpose use on a debug build.

Especially in games, it’s common for only the highly optimised release builds to have playable performance.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#222

Post by nonethewiser »

senda wrote: post #17
maz1b wrote: post #9

I always enjoy reading deeply technical writeups like these. I only wonder how much more rare they may or may not get in the AI era.

i think the shift will be from craftmens to trademens in regards to general software engineers, but these are type of writes up stem of a artisan style all to its own.

Compare python devs of today to fortran devs of the 60s. Something like that distance. Maybe more. But the trend isnt new.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#224

Post by voidspark »

devnullbrain wrote: post #216
kittoes wrote: post #203

Earlier quoted context omitted.

Really? Someone depending on UB in their software represents the downfall of Microsoft?! What a hot take...

User has working software. User updates operating system. User has broken software. That's a problem for the party trying to sell operating system updates.

The software was fundamentally broken before the OS update. It was working by pure random chance with undefined behaviour. It’s a C++ issue, not an OS issue. The same code compiled for another OS would have different random results.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#225

Post by MBCook »

auxiliarymoose wrote: post #194
GeoAtreides wrote: post #173

Earlier quoted context omitted.

I'm willing to bet it was was done for performance reasons, subtraction is cheaper than float point division. Probably the compiler also has some tricks to optimize this further. There is absolutely no way this could turn into an infinite loop. It could underflow, but for that to happen angle would have to be less than the 2*pi, therefore exiting the loop.

The article discusses how that turns into an infinite loop and causes a hang. When you subtract a small float from a very large float, the value doesn't change. This is because the "steps" between float values increase with the size of the value (i.e. floats have coarser resolution for larger magnitudes) To see this in action, try running the following in a JavaScript interpreter: console.log(1_000_000_000_000_000_00…

But that’s “impossible”. It’s an angle between 0 and 2pi. When transformed it might go over a bit so they added the check.

It will “never” become big.

So why check? It’s unnecessary.

Thus the bug.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#226

Post by mjevans »

neuroelectron wrote: post #219
bri3d wrote: post #116

Earlier quoted context omitted.

There are various compiler options like -ftrivial-auto-var-init to initialize uninitialized variables to specific (or random) values in some situations, but overall, randomizing (or zeroing) the full content of the stack in each function call would be a horrendous performance regression and isn't done for this reason.

There are fast instructions (e.g., REP STOSx, AVX zero stores, dc zva) and tricks (MTE, zero pages), but no magic CPU instruction exists that transparently and efficiently randomizes or zeros the stack on function calls. You think there would be one and I bet there are on some specialized high-security systems, but I'm not sure even where you would find such a product. Telecom certainly isn't it.

You couldn't do random, but with a predictable performance hit to memory, cache and write-line use stack addresses COULD be isolated for a program, for a library, etc.

It'd be expensive though; every context switch would require it's own stack and pushing / restoring one more register. There's GOOD reason programs don't work that way and are supposed to not rely on values outside of properly initialized (and not later clobbered) memory.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#227

Post by mjevans »

cadamsdotcom wrote: post #190

It has always been too easy to read & write beyond the stack. This should fail, plain and simple. Mitigations exist - ASLR, NX pages, stack-smashing protection etc. but nothing comprehensively stops reads of stale data beyond the stack. Thought experiment for a moment. What if the hardware ensures the unused part of a stack region cannot be read or written. There are many ways to skin this cat, here’s one based aroun…

Any solution I can think of uses a lot of resources. Those sort of methods are useful in some contexts, such as highly secure operations, but seem very excessive for the sort of abuse and leak encountered in this example.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#228

Post by voidspark »

userbinator wrote: post #182

On Windows 11 24H2, more stack space was modified by a new implementation of Critical Sections. IMHO this shows the downfall of Microsoft. Why did they do that? Critical sections have been there for many decades and should be basically bug-free by now. My best guess is someone thought they'd "improve" things and rewrote it, then made some microbenchmark that maybe showed the dubious improvement. The other comment her…

This is an existing bug in GTA, not Windows 11.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#229

Post by throwaway2037 »

frollogaston wrote: post #159
amenghra wrote: post #98

IMHO, if something isn’t part of the contract, it should be randomized. Eg if iteration order of maps isn’t guaranteed in your language, then your language should go out of its way to randomize it. Otherwise, you end up with brittle code: code that works fine until it doesn’t.

Randomization at this level would be too expensive. There are tools that do this for debug purposes, and your stuff runs a lot slower in that mode.

I had to Google to find the tid bit that I read about Perl years ago. I think this will affect iteration order of dicts.

    > Nov 22, 2012 — Perl 5.18 will introduce per process hash randomization and almost certainly will feature a new hash function.

Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#230

Post by dwattttt »

timewizard wrote: post #217
tantalor wrote: post #169

Earlier quoted context omitted.

Nope. You have to remember https://www.hyrumslaw.com/ With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. If you promise randomization, then somebody will depend on that :) And then you can never remove it!

> If you promise randomization You don't. You say the order is undefined.

You can randomly not randomise it :)
Post reply on HN