Live data from Hacker News

Doom crash after 2.5 years of real-world runtime confirmed on real hardware

lenowo.org

131–140 of 221 posts

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#131

2038 is going to be a fun year.

You have 13 years to upgrade to 64-bit ints or switch to a long long for time_t. Lots of embedded stuff or unsupported closed-source stuff is going to need special attention or to be replaced.

I know the OpenFirmware in my old SunServer 600MP had the issue. Unfortunately I don’t have to worry about that.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#132

Earlier quoted context omitted.

I opened this on an iPhone which has fewer adblock options. Desktop is better locked down. Regardless I can still complain about how intrusive the ads are.

Don't accept devices that limit your ad blocker options.

Does this discussion strike you as one where I’m deliberating whether or not to chuck my smartphone and buy into a new ecosystem to avoid ads on fandom?

These types of comments are always very unhelpful.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#133

About a year ago I was looking at Crash Bandicoot timer systems and I found that Crash 3 has a constantly incrementing int32. It only resets if you die. Left for 2.26 years, it will overflow. When it does finally overflow, we get "minus" time and the game breaks in funny ways. I did a video about it: https://youtu.be/f7ZzoyVLu58

Is it common to default to a signed integer for tracking a timer? I realize being unsigned it would still overflow but at least you'd get twice the time, no?

[deleted]

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#134

Earlier quoted context omitted.

I think many games were that way. SotN definitely has a global timer. On a native 32-bit system it makes sense, especially when the life of a game was a few months to a few years on the retail shelf. No player is going to leave their system running for 2.27 years so what’s the point of even tesing it? Who knew at the time they were creating games that would be disassembled, deconstructed, reverse engineered. Do any o…

Let's say youre pedantic with code. Ive been trying to be lately - clippy has an ovefflow lint for rust i try to use. Error: game running for two years, rebooting so you cant cheese a timer. Does this make the bug any better handled? Bugs like this annoy me because they arent easily answered.

There are always limits to what a program can do. The only fix is to choose large enough integers (and appropriate units) so that you can represent long enough times / large enough sizes / etc. that anyone could reasonably encounter. What sizes make sense also include how they impact performance and for a game from the 32-bit era, a crash (controlled abort or not) after over two years is probably a better choice than slowing everything down by using a 64-bit integer.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#135
Once upon a time, Windows NT 4 had a similar bug. Their counter was high precision, though, and was for uptime of the system. Back before Service Pack 3 (or was it SP2?) we had a scheduled task reboot the system on the first of the month. Otherwise it would crash after about 42 days of uptime, because apparently nobody at Microsoft tested their own server OS to run for that long.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#136
post #89

Does that hardware traps overflows or something? I had read an article about how DOOMs engine works and noticed how a variable for tracking the demo kept being incremented even after the next demo started. This variable was compared with a second one storing its previous value Doesn't sound like something that would crash, I wonder what was the actual crash

Signed overflow is undefined behavior in C, so pretty much anything could happen. Though this crash seems to be deterministic between platforms and compilers, so probably not about that. TFA says the variable is being compared to its previous value, and that comparison presumably assumes new < old cannot happen. And when it does, it could easily lead to eg. stack corruption. C after all happily goes to UB land if, fo…

Just because the language standard allows for anything to happen doesn't mean that actually anything can happen with real compilers. It's still a good question to think about how it could actually lead to a crash.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#137

Earlier quoted context omitted.

> Microsoft pretty much owns most of PC gaming. So valve next?

They missed that window when Sierra was still the publisher for Half-Life. Besides, Valve is not a publicly traded company and Gabe Newell as former manager at Microsoft has no interest in getting back together. Valve is betting everything on Linux right now to be more independent from Microsoft.

> Valve is betting everything on Linux right now...

They've been working on Linux support since at least around the time that Microsoft introduced the Windows Store... so for the last twelve years or so.

And, man, a couple of months ago I figured out how to run Steam as a separate user on my Xorg system. Not-at-all-coincidentally, I haven't booted into Windows in a couple of months. Not every game runs [0], but nearly every game in my library does.

I'm really gladdened by the effort put in to making this work.

[0] Aside from the obvious ones with worryingly-intrusive kernel-level anticheat, sometimes there are weird failures like Highfleet just detonating on startup.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#138
post #116

Earlier quoted context omitted.

Are there not industrial ones meant to last longer? Maybe you can buy a used but good condition one of those.

There are, and if you really have the workload that you need to cook stuff 24/7 (what in gods name is OP cooking btw?) then you should definitely get one of those. Maybe not even secondhand but just a new one. The cheap consumer grade ones are meant for people who use them once or twice a year. This is a fine example of what I meant about people complaining when they use products beyond their design parameters.

I got one that seems to be kind of in the middle, it's better built than most of the consumer models but not quite as "industrial" feeling as some of the commercial models. I use it a few times a week for a few hours each.

I'm on a mostly carnivore, mostly ruminant meat diet and for costs tend to do a lot of ground beef... I sous vide a bunch of burgers in 1/2lb ring molds, refrigerate and sear off when hungry. This lets me have safer burgers that aren't overcooked. I do 133F for 2.5+ hours.

I also do steaks about once or twice a week. I have to say it's probably the best kitchen investment I could have made in terms of impact on the output quality.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#139

Earlier quoted context omitted.

That doesn't make sense. If new < old cant happen there is no need to make a comparison. Stack corruption? Nah, its a counter not an index or pointer or it would fail sooner. But then what is the failure? IDK

Um, there are the cases new == old and new > old. And all the more specific cases new == old + n. I haven’t seen the code so this is just speculation, but there are plenty of ways how an unexpected, "can never happen" comparison result causes immediate UB because there’s no execution path to handle it, causing garbage to be returned from a function (and if that garbage was supposed to be a pointer, well…) or even exe…

Dividing by a difference that is suddenly zero is another possibility.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#140

Earlier quoted context omitted.

I run sous vide cookers 24*7, and they uniformly break within 90 days or less. But they don't like to admit their smaller duty cycle, so they don't, and keep sending me warranty replacements instead. I keep buying different brands looking for one with a longer life. I'll bet most people do that when their gadgets die, and purposely making products that die as soon as sold isn't often a successful business model.

Are there not industrial ones meant to last longer? Maybe you can buy a used but good condition one of those.

Definitely -- get something meant for a lab. I worked in one that had a 150F water bath running day and night.
Post reply on HN