5 ms·

When I was a larval programmer, I collected the different types of bugs I found as I debugged my code. This category was my favourite. I once progressively com

by gnat 5y ago

When I was a larval programmer, I collected the different types of bugs I found as I debugged my code. This category was my favourite. I once progressively commented out more and more of a file, trying to find the bit with a bug, until the whole thing was commented out and no source was being compiled yet the original buggy behavior was still there and only THEN did I figure out I was editing a different file than I was compiling. Echoes of this original sin have shown up repeatedly throughout my life, to be point where it's one of the first things I check when my corrective measure has no effect on problematic behavior.

lordnacho 5y ago
What are the other categories?
the_af 5y ago
I've been hit enough times with this bug, now it's one of the first things I test. Just printing something in order to check I'm editing the right file, even before trying to fix the actual bug!
- salawat 5y ago
  Not really a bug though. That's operator error. This week I've seen multiple people stumbling over that, and it's gotten to the point I question whether people understand filesystems anymore. Half the reason for them is to provide an abstraction that maps a spacelike addressable quality to data to be operated on. It's an extension on the more general concept of namespaces. What's the difference between data HERE and data THERE. different path. Even with stuff like git or other VCS's where you fudge the spacelike mapping with an extra layer of time-like addressing... This is the content HERE from 3 revision's ago vs. the content HERE now vs the content over THERE either now that or 3 revisions ago... I have to train people to break them of the habit/hubris of thinking they are "smarter" or more "accurate" at computation than the computer is. If you take the meaning of compute to be "creatively navigating to a solution in a problem space, humans win hand down. If you define it as reliably doing the same thing over and over again, give up. The silicon has you beat. Always check your assumptions against what the machine is actually doing. Checklist if necessary. That puts you on a footing where you can actually outdo the computer in both realms. Or don't and be reminded once again of why being human is the most pitiable form of cognitive logic, where it takes hard work just to ensure a consistent response to similar classes of stimulus over time, and where remembering and recalling things is totally non-trivial. In the quest for staying alive in a dynamic world doing it's best to kill us, our brain does great. In a world in which it'd be nice not to be reminded by my equipment of my own idiocy on a regular basis, not do much.
  - kodah 5y ago
    A programmers view of code isn't exactly one to one with a filesystem though, so I don't think it's that programmers have trouble understanding filesystems. Instead, I think it's that many languages push us into particular paradigms of code organization. That filesystem now quickly reflects the programmers mental model of the application within the confines of the language. Often in those paradigms I find that there's layers to a single feature; for instance, it may be implemented via a hook that calls a controller that calls a service. Those layers exist to group code and to allow for future development, but they can also get confusing about what you're touching in large codebases.
  - gnat 5y ago
    You're right, it's a meta-bug. It's a bug in your debugging process. You think you have a problem. You change the wrong file to find out. Now you have two problems. And if you're lucky, it won't take you fifteen minutes to figure that out.
- deleted 5y ago
  [deleted]
- travisjungroth 5y ago
  Get control, extend control. Getting control means making the system do something of your choosing. It’s not the thing you really want (until you’re done), but it’s something you decided. In your case, printing. Extend control means make it do something else you want. This should be a small step. It’s surprising how few small steps you need to get a pretty complex system going. Here you might print from the function you’re fixing. Sometimes when you go to extend control, the system won’t do what you want. You’re surprised. This means you’ve lost control. The good thing is because you took a small step (right?) the problem is now in a narrow space. Get control again. Either go back to what you did before, or take the smallest possible step forward from there. You will spend all your time with a system you either can control or nearly can. This ways of debugging is slower than how most people do it in the median case, but much faster in the mean. Debugging time is dominated by the worst cases, and this real cuts down on those. Especially the ones that make you feel dumb. A critical thing is to not just “check” but “do”. If you have a computer that won’t power up, you don’t just check it’s plugged in, that’s not controlling anything. You plug in another computer or electric heater. This way of working is rather peaceful. Much less frustrating than how most people do it. The most frustrating part is when someone asks for your help and tells you not to bother checking that thing, they know it works. And that part, and that part, and that part. But somehow this system they have complete confidence in as parts doesn’t do what they want in the whole. Best phrase for this situation: “Well, let’s just try it for fun.”
  - ema 5y ago
    Yes, debugging is as much about finding out where one's assumptions are wrong as is is about finding out where the software has a defect.
Akronymus 5y ago
This is why, when compiling, I have "everything" pulled up, sorted by change timestamp and check if the file I care about actually has changed.
8n4vidtmkvmk 5y ago
i had an nginx "bug" where it was serving an old version of a file. i deleted the file and hard refreshed and it still served it up happily. turns out i had static gzip compression enabled and never deleted the corresponding gz file
segfaultbuserr 5y ago
Fun fact: Unix Makefile was invented as a result of this incident. > Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. - Stuart Feldman
- Too 5y ago
  Oh the irony. Makefiles has been the number one source of this issue itself. Usually due to badly specified transitive dependencies. Like only rebuild .o files on changes to .c files but forget completely about changes to .h files etc. Removed c files leaving stale .o files still being linked in is another favorite. But yeah, I guess the predecessor it replaced must have been even worse. Today we can have higher expectations.
  - NieDzejkob 5y ago
    My favorite solution is Tup, which uses FUSE to observe exactly which files each command is reading. That way it's impossible to write a Tupfile for which incremental builds don't work properly.
    - iforgotpassword 5y ago
      I was actually thinking of this approach once but immediately convinced myself it's crazy. Good to see it seems to work at least. :-)
  - rustybolt 5y ago
    I also remember changing the makefile, mindlessly running 'make' without looking at the output, then running the program and wondering why the program isn't behaving differently.
ithkuil 5y ago
This class of issues is so common in my personal experience that very often I intentionally introduce some sort of panic/assertions in the place that I want to fix, just to be 100% sure I'm a) editing the right source b) the tooling (compiler, ci, ...) is actually doing what I expect. Most of the time it's unnecessary, but when it catches such issues it saves countless hours of frustration.

by gnat 5y ago

lordnacho 5y ago

What are the other categories?

the_af 5y ago

I've been hit enough times with this bug, now it's one of the first things I test. Just printing something in order to check I'm editing the right file, even before trying to fix the actual bug!

salawat 5y ago
Not really a bug though. That's operator error. This week I've seen multiple people stumbling over that, and it's gotten to the point I question whether people understand filesystems anymore. Half the reason for them is to provide an abstraction that maps a spacelike addressable quality to data to be operated on. It's an extension on the more general concept of namespaces. What's the difference between data HERE and data THERE. different path. Even with stuff like git or other VCS's where you fudge the spacelike mapping with an extra layer of time-like addressing... This is the content HERE from 3 revision's ago vs. the content HERE now vs the content over THERE either now that or 3 revisions ago... I have to train people to break them of the habit/hubris of thinking they are "smarter" or more "accurate" at computation than the computer is. If you take the meaning of compute to be "creatively navigating to a solution in a problem space, humans win hand down. If you define it as reliably doing the same thing over and over again, give up. The silicon has you beat. Always check your assumptions against what the machine is actually doing. Checklist if necessary. That puts you on a footing where you can actually outdo the computer in both realms. Or don't and be reminded once again of why being human is the most pitiable form of cognitive logic, where it takes hard work just to ensure a consistent response to similar classes of stimulus over time, and where remembering and recalling things is totally non-trivial. In the quest for staying alive in a dynamic world doing it's best to kill us, our brain does great. In a world in which it'd be nice not to be reminded by my equipment of my own idiocy on a regular basis, not do much.
- kodah 5y ago
  A programmers view of code isn't exactly one to one with a filesystem though, so I don't think it's that programmers have trouble understanding filesystems. Instead, I think it's that many languages push us into particular paradigms of code organization. That filesystem now quickly reflects the programmers mental model of the application within the confines of the language. Often in those paradigms I find that there's layers to a single feature; for instance, it may be implemented via a hook that calls a controller that calls a service. Those layers exist to group code and to allow for future development, but they can also get confusing about what you're touching in large codebases.
- gnat 5y ago
  You're right, it's a meta-bug. It's a bug in your debugging process. You think you have a problem. You change the wrong file to find out. Now you have two problems. And if you're lucky, it won't take you fifteen minutes to figure that out.
deleted 5y ago
[deleted]
travisjungroth 5y ago
Get control, extend control. Getting control means making the system do something of your choosing. It’s not the thing you really want (until you’re done), but it’s something you decided. In your case, printing. Extend control means make it do something else you want. This should be a small step. It’s surprising how few small steps you need to get a pretty complex system going. Here you might print from the function you’re fixing. Sometimes when you go to extend control, the system won’t do what you want. You’re surprised. This means you’ve lost control. The good thing is because you took a small step (right?) the problem is now in a narrow space. Get control again. Either go back to what you did before, or take the smallest possible step forward from there. You will spend all your time with a system you either can control or nearly can. This ways of debugging is slower than how most people do it in the median case, but much faster in the mean. Debugging time is dominated by the worst cases, and this real cuts down on those. Especially the ones that make you feel dumb. A critical thing is to not just “check” but “do”. If you have a computer that won’t power up, you don’t just check it’s plugged in, that’s not controlling anything. You plug in another computer or electric heater. This way of working is rather peaceful. Much less frustrating than how most people do it. The most frustrating part is when someone asks for your help and tells you not to bother checking that thing, they know it works. And that part, and that part, and that part. But somehow this system they have complete confidence in as parts doesn’t do what they want in the whole. Best phrase for this situation: “Well, let’s just try it for fun.”
- ema 5y ago
  Yes, debugging is as much about finding out where one's assumptions are wrong as is is about finding out where the software has a defect.

Akronymus 5y ago

This is why, when compiling, I have "everything" pulled up, sorted by change timestamp and check if the file I care about actually has changed.

8n4vidtmkvmk 5y ago

i had an nginx "bug" where it was serving an old version of a file. i deleted the file and hard refreshed and it still served it up happily. turns out i had static gzip compression enabled and never deleted the corresponding gz file

segfaultbuserr 5y ago

Fun fact: Unix Makefile was invented as a result of this incident. > Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. - Stuart Feldman

Too 5y ago
Oh the irony. Makefiles has been the number one source of this issue itself. Usually due to badly specified transitive dependencies. Like only rebuild .o files on changes to .c files but forget completely about changes to .h files etc. Removed c files leaving stale .o files still being linked in is another favorite. But yeah, I guess the predecessor it replaced must have been even worse. Today we can have higher expectations.
- NieDzejkob 5y ago
  My favorite solution is Tup, which uses FUSE to observe exactly which files each command is reading. That way it's impossible to write a Tupfile for which incremental builds don't work properly.
  - iforgotpassword 5y ago
    I was actually thinking of this approach once but immediately convinced myself it's crazy. Good to see it seems to work at least. :-)
- rustybolt 5y ago
  I also remember changing the makefile, mindlessly running 'make' without looking at the output, then running the program and wondering why the program isn't behaving differently.

ithkuil 5y ago

This class of issues is so common in my personal experience that very often I intentionally introduce some sort of panic/assertions in the place that I want to fix, just to be 100% sure I'm a) editing the right source b) the tooling (compiler, ci, ...) is actually doing what I expect. Most of the time it's unnecessary, but when it catches such issues it saves countless hours of frustration.