Live data from Hacker News

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

lenowo.org

101–110 of 221 posts

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

#101

Literally unplayable, someone should fix that. Doom is actually such a good game, I always go back to it every few years. The 2016 reboot is also pretty fun, but the later two in the series didn’t do it for me.

This caters for people who prefer the classic Doom style of gameplay in FPS games: https://www.reddit.com/r/boomershooters/

Ahh yes, I'm quite happy that a few years ago this has become a trend!

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

#102
post #94

Earlier quoted context omitted.

The Porsche quote reflects a wider design philosophy that says "Ideally, all components of a system lasts as long as the design life of the entire system and there should be no component that lives significantly longer. If there is such a component, it has been overengineered and thus the system will be more expensive to the end consumer than it needs to be.". It kinda skips over maintenance, but overall most people…

Consumer protection laws prevents businesses following this to it’s extreme. For many businesses the ideal would be to just sell stuff that immediately breaks down as soon as it’s sold. It has the fulfilled its purpose from their point of view

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.

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

#103
post #13

Earlier quoted context omitted.

There's a weapon in Final Fantasy 9 which can only be obtained by reaching a lategame area in less than 12 hours of play time, or 10 hours on the PAL version due to an oversight. Alternatively you can just leave the game running for two years until the timer wraps around. Slow and steady wins the race. https://finalfantasy.fandom.com/wiki/Excalibur_II_(Final_Fan...

Lord have mercy fandom really has become unbearable with the ads and pop ups.

Install an ad blocker.

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

#104

Earlier quoted context omitted.

Lord have mercy fandom really has become unbearable with the ads and pop ups.

Install an ad blocker.

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.

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

#105

Earlier quoted context omitted.

Consumer protection laws prevents businesses following this to it’s extreme. For many businesses the ideal would be to just sell stuff that immediately breaks down as soon as it’s sold. It has the fulfilled its purpose from their point of view

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.

That’s not a small cycle count for a normal household. 90 × 24 = 2,160 total hours.

I sous vide now and then, about twice a week for 6 hours each, so around 12 hours a week. That works out to roughly 15 years of usable machine time for the average person.

Not bad at all.

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

#106

Earlier quoted context omitted.

Install an ad blocker.

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.

There are many ad block options on iPhone. I currently use Wipr 2, but in the past I've used both 1Blocker and AdBlock Pro with success.

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

#107
post #13

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

There's a weapon in Final Fantasy 9 which can only be obtained by reaching a lategame area in less than 12 hours of play time, or 10 hours on the PAL version due to an oversight. Alternatively you can just leave the game running for two years until the timer wraps around. Slow and steady wins the race. https://finalfantasy.fandom.com/wiki/Excalibur_II_(Final_Fan...

We should rally together to force game companies to use 32 bit timers rather than 64bit ones so we can keep finding these fun little glitches. The time to protect overflows is now! ;)

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

#108
post #89

Earlier quoted context omitted.

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…

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 execution never hitting a `ret` and just proceeding to execute whatever is next in memory.

Another super easy way to enter UB land by assuming an integer is nonnegative is array indexing.

  int foo[5] = { … }
  foo[i % 5] = bar;
Everything is fine as long as i isn’t negative. But if it is… (note that negative % positive == negative in C)

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

#109

Earlier quoted context omitted.

Consumer protection laws prevents businesses following this to it’s extreme. For many businesses the ideal would be to just sell stuff that immediately breaks down as soon as it’s sold. It has the fulfilled its purpose from their point of view

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.

Well from an evil business perspective their options are either

- the product doesn't break and you don't buy a replacement from them because you still have a working product

- the product breaks and there is a greater than 0% chance that you will buy a replacement product from them

Of course in practice it's more complicated but I wouldn't be so quick to declare that the math doesn't work out.

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

#110

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.

That’s not a small cycle count for a normal household. 90 × 24 = 2,160 total hours. I sous vide now and then, about twice a week for 6 hours each, so around 12 hours a week. That works out to roughly 15 years of usable machine time for the average person. Not bad at all.

Assuming linearity, which I doubt is the case.
Post reply on HN