31–40 of 85 posts
From what thine is this? It says "There IS a bug ... NOW patched" Should make no sense anyway but I see no time attached to this.
Is there a good way to test for bugs like this during development? Since it’s not particularly realistic to pause development for two months to see what a given build does after that long.
The same way you test for leap-year bugs, write unit-tested code that tests all your boundary conditions.
Very different than something which only happens after 50 days because obviously in small intervals it's not a noticeable bug.
Is there a good way to test for bugs like this during development? Since it’s not particularly realistic to pause development for two months to see what a given build does after that long.
Our company does soak/longevity testing. Typically we'll take a build and let it run for a few weeks during development to find memory leaks. Then the final release enters our longevity lab where we put it under some amount of load and let it run until the device or VM is retired. It won't necessarily find the bug before final release, we could either recall that version or submit an immediate maintenance version tha…
Is there a good way to test for bugs like this during development? Since it’s not particularly realistic to pause development for two months to see what a given build does after that long.
Our company does soak/longevity testing. Typically we'll take a build and let it run for a few weeks during development to find memory leaks. Then the final release enters our longevity lab where we put it under some amount of load and let it run until the device or VM is retired. It won't necessarily find the bug before final release, we could either recall that version or submit an immediate maintenance version tha…
Earlier quoted context omitted.
The same way you test for leap-year bugs, write unit-tested code that tests all your boundary conditions.
Hmm that doesn't seem to be the same thing.. it's easy to test for leap-year, that's a simple case you can either test in the code or literally change your computer clock and let it rollover to see what happens. Very different than something which only happens after 50 days because obviously in small intervals it's not a noticeable bug.
But more to the point - the consumers of GetTickTime should have also had tests to verify that the consuming code appropriately handles time rollovers.
Granted, this was Win95 so I'll cut them some slack, but that should be standard procedure for any code that consumes an incrementing counter API. First question should always be - 'how will this code handle a rollover value'?
This is a pretty uninformative article. It doesn't actually say why Windows would crash, as the title promises. It does some trivial math, points out there's an overflow, and then says "Clearly some code in Windows didn’t handle this too well, and Windows hung."
However, timers wrapping around is a very current problem every programmer should be aware of. Not too long ago we had a problem with corrupted video files. After weeks of investigation it turned out that some code used an 32 bit unsigned to count microseconds. Well, that wraps around after approx. 1 h 10 min... Obviously most test cases were videos shorter than that.
This brings up a good meta point: people who like to complain about the quality of software in the modern world almost certainly didn't live through the early[1] days of the industry. This sounds crazy to modern ears, but at the time the idea of a desktop system actually staying booted for a whole month was weird and alien. They just didn't do that. Commercial unixes were better. It was routine to find servers that h…
The problem is not people writing buggy software or them crashing. At least for me problem is we keep on reinventing the wheel, without corresponding increase in productivity. I don't see people cranking s/w better or faster then they did with Delphi in 1998. Instead of standing on shoulders of the giants we disrespect them, our whole industry is built on abusing all the hardware and technology gains for frivolous wars and gains.
Nowadays you don't even get CLOSE to 49 days uptime before Win10 forces you to restart due to updates ;s
In the late ‘90’s I used to brag about my Linux uptime being over a year. And that was a system was directly exposed to the internet. I can’t imagine how many unknown security holes it had during that time.
This brings up a good meta point: people who like to complain about the quality of software in the modern world almost certainly didn't live through the early[1] days of the industry. This sounds crazy to modern ears, but at the time the idea of a desktop system actually staying booted for a whole month was weird and alien. They just didn't do that. Commercial unixes were better. It was routine to find servers that h…
DOS (before) was very, very stable (but of course was not multitasking) and widely used in industrial setups.
Windows NT (before Win9x) and Windows 2000 (right after) were both, very, very stable, I had machines running 24/7/365 that were rebooted once a year or so and for other reasons (maintenance/update, hardware replacement, black outs longer than UPS capability, etc.).