4 ms·

I have an obsession with classifying software bugs into general categories, looking for the "root cause", or more constructively, for a way to avoid entire clas

by jwr 4y ago

I have an obsession with classifying software bugs into general categories, looking for the "root cause", or more constructively, for a way to avoid entire classes of bugs altogether. I've been doing that for more than 20 years now. This bug, if you look into the fix, falls into my "state transition" category. You can (and should) model large parts of your software as a state machine, with explicit transitions and invariant checks. If you do not, you still end up with states, just implemented haphazardly, and sooner or later someone will forget to perform a task or set a variable when transitioning from state to state. This category is my strong contender for #1 problem area in all devices that have a user interface.

gwillen 4y ago
Do you have any writing I can read about your classification? This sounds extremely interesting and useful. (I have some related thoughts, but not 20 years' worth and largely not recorded.)
- ak_111 4y ago
  I second this comment. It will be very interesting to see a rough sketch.
- Lutzb 4y ago
  Reminds me of Orthogonal Defect Classification. Analyze defects for when they were introduced (during development, architectural design and so on) and what caused the introduction of the defect into the system in the first place.
- jwr 4y ago
  Hmm. Perhaps I should get my notes into shape and publish them… I'll think about it. I would need to force myself to post them to HN without looking at the discussion, though.
woojoo666 4y ago
Another way to look at it is, since the bug is from a race condition, modeling your program after functional programming would minimize these bugs
im3w1l 4y ago
I think the root issue is one of which state is the default one. In Android the logged-in state is the default one, and the logged-out state is constructed by taking the logged-in state and essentially hiding it behind a modal. The issue with this is that systems have a tendency to return to their default state. If the modal is dismissed or has a bug that makes it crash or has a memory corruption, or any number of things then the system will return to the default state. I would turn it upside down, and let the logged out state be the default one. The logged-in state is then a lockscreen that is hidden behind a session. If the session dies you are back at the lock screen. The lock screen can't be dismissed because it's always there. If the lockscreen crashes the phone locks up completely because there is nothing else there to show. It's acceptable for failures and exceptions to decrease privilege (boot you out), but they must never increase it. Edit: Ideally the lockscreen should also run with reduced privileges so that it literally can't start a session even if it wants to, except indirectly by supplying a password to some other system.
- underwater 4y ago
  Anything related to security should fail safe. Failure is not lack of rigour, it's from fundamentally flawed architecture.
  - jwr 4y ago
    This begs for the famous quote: "When a fail-safe system fails, it fails by failing to fail-safe." (from the wonderful "Systemantics"). Yes, one should definitely try to fail safe. But managing your states and state transitions explicitly and carefully is a good way to avoid these kinds of bugs.
appleflaxen 4y ago
I would like to subscribe to your newsletter.

by jwr 4y ago

gwillen 4y ago

Do you have any writing I can read about your classification? This sounds extremely interesting and useful. (I have some related thoughts, but not 20 years' worth and largely not recorded.)

ak_111 4y ago
I second this comment. It will be very interesting to see a rough sketch.
Lutzb 4y ago
Reminds me of Orthogonal Defect Classification. Analyze defects for when they were introduced (during development, architectural design and so on) and what caused the introduction of the defect into the system in the first place.
jwr 4y ago
Hmm. Perhaps I should get my notes into shape and publish them… I'll think about it. I would need to force myself to post them to HN without looking at the discussion, though.

woojoo666 4y ago

Another way to look at it is, since the bug is from a race condition, modeling your program after functional programming would minimize these bugs

im3w1l 4y ago

I think the root issue is one of which state is the default one. In Android the logged-in state is the default one, and the logged-out state is constructed by taking the logged-in state and essentially hiding it behind a modal. The issue with this is that systems have a tendency to return to their default state. If the modal is dismissed or has a bug that makes it crash or has a memory corruption, or any number of things then the system will return to the default state. I would turn it upside down, and let the logged out state be the default one. The logged-in state is then a lockscreen that is hidden behind a session. If the session dies you are back at the lock screen. The lock screen can't be dismissed because it's always there. If the lockscreen crashes the phone locks up completely because there is nothing else there to show. It's acceptable for failures and exceptions to decrease privilege (boot you out), but they must never increase it. Edit: Ideally the lockscreen should also run with reduced privileges so that it literally can't start a session even if it wants to, except indirectly by supplying a password to some other system.

underwater 4y ago
Anything related to security should fail safe. Failure is not lack of rigour, it's from fundamentally flawed architecture.
- jwr 4y ago
  This begs for the famous quote: "When a fail-safe system fails, it fails by failing to fail-safe." (from the wonderful "Systemantics"). Yes, one should definitely try to fail safe. But managing your states and state transitions explicitly and carefully is a good way to avoid these kinds of bugs.

appleflaxen 4y ago

I would like to subscribe to your newsletter.