Earlier quoted context omitted.
Raymond is a wizard. Read his blogs for many years and love his style and knowledge.
Raymond knows everything. From microcode bugs on Alpha AXP to template meta programming to UI.
[flagged]
How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
211–220 of 315 posts
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#212Earlier quoted context omitted.
It looks like the utilized stack, or a stack protection area, increased.
When I worked at Microsoft and I had downtime I would sometimes read the code for app compatibility shims out of pure curiosity. Win9x video games that made bad assumptions about the stack were a theme I saw. One of the differences between win9x and NT based windows is that kernel32 (later kernelbase) is a now user mode wrapper atop ntdll, whereas in the olden days kernel32 would trap directly into the kernel. This m…
I wonder how many people think of the call stack as running left to right, most recent return first, rather than top to bottom, likewise? If you stare at enough hex dumps, it makes perfect sense.
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#213> Not ignore the compilation warnings – this code most likely threw a warning in the original code that was either ignored or disabled! What compiler error would you expect here? Maybe not checking the return value from scanf to make sure it matches the number of parameters? Otherwise this seems like a data file error that the compiler would have no clue about.
Trying g++ version 11.4, there's no warning by default if you don't check the return value of sscanf. Even `g++ -Wall -Wextra -Wunused-result` produces no warnings for a small example.
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#214My takeaway, speaking as someone who leans towards functional programming and immutability, is "this is yet another example of a mutability problem that could never happen in a functional context" (so, for example, this bug would have never been created by Rust unless it was deeply misused)
The constant rust evangelism on this site is such a turn off from actually wanting to use the language.
There'd be a lot less Rust evangelism on this site if there were less UB bug outcomes on this site.
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#215Earlier quoted context omitted.
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.
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.
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#216On 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…
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.
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#217IMHO, 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.
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.
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#218Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#219IMHO, 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.
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.
Re: How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2
#220IMHO, 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.
I once updated a little shy of 1mloc of Perl 5.8 code to run on Perl 5.32 (ish). There were, overall, remarkably few issues that cropped up. One of these issues (that showed itself a few times) was more or less exactly this: the iteration order through a hash is not defined. It has never been defined, but in Perl 5.8 it was consistent: for the same insertion order of the same set of keys, a hash would always iterate in the same way. In a later Perl it was deliberately randomised, not just once, but on every iteration through the hash.
It turned out there a few places that had assumed a predictable - not just stable, but deterministic - hash key iteration order. Mostly this showed up as tests that failed 50% of the time, which suggested to me a rough measure of how annoying an error is to track down is inversely correlated with how often the error appears in tests.
(Other issues were mostly due to the fact that Perl 5 is all but abandoned by its former community: a few CPAN modules are just gone, some are so far out of date that they can't be coerced to still work with other modules that have been updated over time. )