3 ms·

In that situation you’d generally use conditional breakpoints. If you’re just scrubbing up and down in thousands of lines of output looking for something fishy,

by thom 7y ago

In that situation you’d generally use conditional breakpoints. If you’re just scrubbing up and down in thousands of lines of output looking for something fishy, that doesn’t seem very productive. I’m also on board with generative testing to find these sorts of edge cases, if relevant.

pjc50 7y ago
It's the "how did I get here?" question: you have a clear logfile marker for "something went wrong", such as a stack trace, and then scroll back upwards to determine what went wrong. Can even be a negative, which is incredibly hard to do with breakpoints: "I should be seeing line X after Y or before Z, but it's not there" Can also be a ward against the insecurity of unknown unknowns - where there's a lot of moving parts and the problem isn't well isolated (we'd all like it to be, but maybe previous developers didn't design the system like that) or the OS or one of your libraries is betraying you.
- thom 7y ago
  Sure, I’m not really saying every problem in software can be solved with a debugger. But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence. Obviously shit happens (or happened in the past) and you’ve sometimes gotta do what you gotta do though.
  - pjc50 7y ago
    > But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence I think there's a kind of reverse Amdahl's law at work here. Situations where there is a nice clean crash into the debugger that tells you what's going on are easy - so they don't take up much time. Situations where that doesn't work take much longer - maybe the problem doesn't replicate when you're using the debugger. And there have been situations where simply doing the data-gathering to establish that a bug was real consumes weeks. My own personal one of those was missed touchscreen events; because they were so infrequent we eventually had to set up a robot to press the screen 10,000 times, resulting in 9,999 touch events, and record a huge amount of data up and down the stack in order to work out what had happened.
    - thom 7y ago
      Then I shall count my blessings, both past and present.
badsectoracula 7y ago
I've found most "conditions" in conditional breakpoints to be very limiting, especially if i want to query objects and the debugger cannot do that. Usually i start with printf and then i just modify the code with something like "if (condition) __debugbreak();" (or the langage equivalent).

by thom 7y ago

pjc50 7y ago

It's the "how did I get here?" question: you have a clear logfile marker for "something went wrong", such as a stack trace, and then scroll back upwards to determine what went wrong. Can even be a negative, which is incredibly hard to do with breakpoints: "I should be seeing line X after Y or before Z, but it's not there" Can also be a ward against the insecurity of unknown unknowns - where there's a lot of moving parts and the problem isn't well isolated (we'd all like it to be, but maybe previous developers didn't design the system like that) or the OS or one of your libraries is betraying you.

thom 7y ago
Sure, I’m not really saying every problem in software can be solved with a debugger. But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence. Obviously shit happens (or happened in the past) and you’ve sometimes gotta do what you gotta do though.
- pjc50 7y ago
  > But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence I think there's a kind of reverse Amdahl's law at work here. Situations where there is a nice clean crash into the debugger that tells you what's going on are easy - so they don't take up much time. Situations where that doesn't work take much longer - maybe the problem doesn't replicate when you're using the debugger. And there have been situations where simply doing the data-gathering to establish that a bug was real consumes weeks. My own personal one of those was missed touchscreen events; because they were so infrequent we eventually had to set up a robot to press the screen 10,000 times, resulting in 9,999 touch events, and record a huge amount of data up and down the stack in order to work out what had happened.
  - thom 7y ago
    Then I shall count my blessings, both past and present.

badsectoracula 7y ago

I've found most "conditions" in conditional breakpoints to be very limiting, especially if i want to query objects and the debugger cannot do that. Usually i start with printf and then i just modify the code with something like "if (condition) __debugbreak();" (or the langage equivalent).