3 ms·

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not nece

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.) As an example, I play a very old video game (Descent). One of the major problems with one of the modern source ports is that the game crashed under certain conditions -- like if it received a malformed data packet. This is a game that's already fairly tolerant to lost data, so just dropping a bad packet is an acceptable result. By comparison, crashing in the middle of a competitive match is a much worse result, because it affects things like momentum and where various powerups have been left around the map. It would be great to fix the bug that was resulting in malformed packets -- but the cost of directly affecting a high-stakes match is not worth it. I'd rather tolerate a fraction of a percent of lost data every game for the next 20 years than ever have a high-stakes match where the result was tainted by a badly-timed crash.

zubat 10y ago
There are two use cases there that end up with a conflict of interest: One is the UX of having a crash during an important play session(high stakes match) and the other is the developer ease of tracing and debugging errors, which favors crashing over letting erroneous behavior taint the whole system. In practice this means that during development you want the game to fail fast and loudly so that the biggest bugs are taken care of, but gradually add features to fail more quietly later, e.g. by moving more errors into logs and traces.
- lotharbot 10y ago
  Exactly right. Test builds can crash; production builds should log errors (and perhaps inform the user).
  - cperciva 10y ago
    This is a very good strategy for getting dangerous security flaws. BIND's security has improved dramatically since they went all-out on assertions; at least 1/3 of the "crash" bugs would have been remote code execution without the protective crashing.
    - lotharbot 10y ago
      sure, that's one of the tradeoffs. For some types of software, that's a dominant consideration. For others, it has little or no relevance.
kelnos 10y ago
That's looking at it the wrong way. The bug is not that it received a malformed packet: any network-aware program must expect to receive bad data and avoid crashing or other undesirable behavior when receiving bad data. Sure, the player's software on the other end should not have sent the malformed packet, but crashing on bad untrusted input is a bug of its own, and I'd say a worse one. (And who knows, maybe the malformed packet wasn't caused by a bug on the other side, but by something malicious, or perhaps some sort of network-caused data corruption.)
- lotharbot 10y ago
  There were several other conditions that would cause the game to crash, which were more reasonable to just play through, aside from the malformed packet handling. The overall point here is that there is a real cost to making your software crash. Most of your users want software that is stable, and crashing is often worse than doing the wrong thing and continuing to run in a slightly janky state.
lmm 10y ago
If it were possible to gain an advantage in a competitive match by having your system deliberately drop a packet, the game would quickly become impossible to play competitively - that kind of cheating would be basically impossible to detect because there's no way to tell it apart from a genuine bad internet connection. If you've carefully thought through what the game should do when a packet is malformed that's one thing, but if you haven't thought about it then cleanly crashing is probably the best option.
- MichaelBurge 10y ago
  That isn't true at all: Often competitive players are required to use the tournament organizer's hardware anyways. And often competitive players form groups to play in, so everybody knows each other even while practicing. You'd probably want to be on a LAN to minimize the risk of this happening accidentally. So in practice, I don't think it would matter too much even if money was on the line. You would just have to take appropriate precautions, and watch to disqualify people for cheating.
- lotharbot 10y ago
  > "cleanly crashing is probably the best option" Except that it's also possible to gain an advantage by causing a game crash. Ultimately, "crash the game" is among the worst possible options. (Also ultimately, it's a very old open-source game in which it's relatively easy to compile your own client software, so "make the game crash as an anti-cheat method" only works on honest players anyway.)

zubat 10y ago

There are two use cases there that end up with a conflict of interest: One is the UX of having a crash during an important play session(high stakes match) and the other is the developer ease of tracing and debugging errors, which favors crashing over letting erroneous behavior taint the whole system. In practice this means that during development you want the game to fail fast and loudly so that the biggest bugs are taken care of, but gradually add features to fail more quietly later, e.g. by moving more errors into logs and traces.

lotharbot 10y ago
Exactly right. Test builds can crash; production builds should log errors (and perhaps inform the user).
- cperciva 10y ago
  This is a very good strategy for getting dangerous security flaws. BIND's security has improved dramatically since they went all-out on assertions; at least 1/3 of the "crash" bugs would have been remote code execution without the protective crashing.
  - lotharbot 10y ago
    sure, that's one of the tradeoffs. For some types of software, that's a dominant consideration. For others, it has little or no relevance.

kelnos 10y ago

That's looking at it the wrong way. The bug is not that it received a malformed packet: any network-aware program must expect to receive bad data and avoid crashing or other undesirable behavior when receiving bad data. Sure, the player's software on the other end should not have sent the malformed packet, but crashing on bad untrusted input is a bug of its own, and I'd say a worse one. (And who knows, maybe the malformed packet wasn't caused by a bug on the other side, but by something malicious, or perhaps some sort of network-caused data corruption.)

lotharbot 10y ago
There were several other conditions that would cause the game to crash, which were more reasonable to just play through, aside from the malformed packet handling. The overall point here is that there is a real cost to making your software crash. Most of your users want software that is stable, and crashing is often worse than doing the wrong thing and continuing to run in a slightly janky state.

lmm 10y ago

If it were possible to gain an advantage in a competitive match by having your system deliberately drop a packet, the game would quickly become impossible to play competitively - that kind of cheating would be basically impossible to detect because there's no way to tell it apart from a genuine bad internet connection. If you've carefully thought through what the game should do when a packet is malformed that's one thing, but if you haven't thought about it then cleanly crashing is probably the best option.

MichaelBurge 10y ago
That isn't true at all: Often competitive players are required to use the tournament organizer's hardware anyways. And often competitive players form groups to play in, so everybody knows each other even while practicing. You'd probably want to be on a LAN to minimize the risk of this happening accidentally. So in practice, I don't think it would matter too much even if money was on the line. You would just have to take appropriate precautions, and watch to disqualify people for cheating.
lotharbot 10y ago
> "cleanly crashing is probably the best option" Except that it's also possible to gain an advantage by causing a game crash. Ultimately, "crash the game" is among the worst possible options. (Also ultimately, it's a very old open-source game in which it's relatively easy to compile your own client software, so "make the game crash as an anti-cheat method" only works on honest players anyway.)