4 ms·

Stepping with a debugger is OK as long as the piece of code you are debugging is more-less single-threaded. If your system is event-based with a ton of backgrou

by kgeist 4y ago

Stepping with a debugger is OK as long as the piece of code you are debugging is more-less single-threaded. If your system is event-based with a ton of background processing, I found that debugging via logging is much simpler to set up and use in that case. It also blurs the line between debugging a problem locally and in production (including post mortem), the skills somewhat transfer. I also often use print() directly because to use a proper logger, I'd need to inject loggers with DI across several classes, import packages, when a simple print to stderr would work as well.

maccard 4y ago
Why do you think print debugging is going to help in a multithreaded scenario? Either your output is going to be wrong because there's no synchronization, you implement buffering which drastically changes the timing of your code and the behaviour, or you lock for printing which again drastically changes the timing and behaviour.
- kgeist 4y ago
  >you implement buffering which drastically changes the timing of your code and the behaviour Well, if slightly different timings changed behavior, I'd consider it a bug. The microservice systems I usually develop have strong guarantees of processing order via work queues (first in, first out), various stateless components communicate only through channels/queues (shared nothing) and different timings from run to run are absolutely expected because of the unpredictability of the network and external components. The rate of processing events in the queue, when debugging locally, isn't usually too high to "break" the output (i.e. when it's interleaved from multiple workers), even though it happens sometimes, but only if it's in-process. If a thread of execution is its own container instance, they'll have their own stderr output attached, so there's nothing to synchronize. I understand what you're talking about, something like audio/video processing software or gamedev would suffer from printing as it would mess up the timings. But I'm not sure if stepping with a debugger is any better in that case.
  - maccard 4y ago
    > Well, if slightly different timings changed behavior, I'd consider it a bug If you're debugging, you already have a bug that you're investigating. Let's say it's a race condition - if you isolate it to a certain function there's no guarantee that adding prints will actually show you the state of what you're computing without the prints. > But I'm not sure if stepping with a debugger is any better in that case. No, it's definitely not. There's absolutely no guarantee with a debugger that what you're looking at is the state of the bug either. But saying that you can debug multithreaded code with prints is just false.
    - kgeist 4y ago
      >But saying that you can debug multithreaded code with prints is just false Not every bug in multithreaded programming is a race condition bug, I'm not sure why you are equating "debugging a multithreaded program" with "debugging a race condition". If your program consists of stateless shared-nothing workers which take an input and produce an output, most of the state operated on according to business rules is local to the worker and the current request, with no shared state (in memory at least). In my experience, with this kind of setup, most of the bugs are logic bugs and silly programming errors, not race conditions. The problem is that data can be passed from worker to worker between threads, processes, machines, and it's easier to debug it via logging. I'm not saying you should debug race conditions with print(), but a debugger with stepping won't help you either. It's a hard task in general - to debug race conditions, not sure why it's brought up. Printing/logging at least is useful as a first step to investigate what's going on at all.

by kgeist 4y ago

maccard 4y ago

Why do you think print debugging is going to help in a multithreaded scenario? Either your output is going to be wrong because there's no synchronization, you implement buffering which drastically changes the timing of your code and the behaviour, or you lock for printing which again drastically changes the timing and behaviour.

kgeist 4y ago
>you implement buffering which drastically changes the timing of your code and the behaviour Well, if slightly different timings changed behavior, I'd consider it a bug. The microservice systems I usually develop have strong guarantees of processing order via work queues (first in, first out), various stateless components communicate only through channels/queues (shared nothing) and different timings from run to run are absolutely expected because of the unpredictability of the network and external components. The rate of processing events in the queue, when debugging locally, isn't usually too high to "break" the output (i.e. when it's interleaved from multiple workers), even though it happens sometimes, but only if it's in-process. If a thread of execution is its own container instance, they'll have their own stderr output attached, so there's nothing to synchronize. I understand what you're talking about, something like audio/video processing software or gamedev would suffer from printing as it would mess up the timings. But I'm not sure if stepping with a debugger is any better in that case.
- maccard 4y ago
  > Well, if slightly different timings changed behavior, I'd consider it a bug If you're debugging, you already have a bug that you're investigating. Let's say it's a race condition - if you isolate it to a certain function there's no guarantee that adding prints will actually show you the state of what you're computing without the prints. > But I'm not sure if stepping with a debugger is any better in that case. No, it's definitely not. There's absolutely no guarantee with a debugger that what you're looking at is the state of the bug either. But saying that you can debug multithreaded code with prints is just false.
  - kgeist 4y ago
    >But saying that you can debug multithreaded code with prints is just false Not every bug in multithreaded programming is a race condition bug, I'm not sure why you are equating "debugging a multithreaded program" with "debugging a race condition". If your program consists of stateless shared-nothing workers which take an input and produce an output, most of the state operated on according to business rules is local to the worker and the current request, with no shared state (in memory at least). In my experience, with this kind of setup, most of the bugs are logic bugs and silly programming errors, not race conditions. The problem is that data can be passed from worker to worker between threads, processes, machines, and it's easier to debug it via logging. I'm not saying you should debug race conditions with print(), but a debugger with stepping won't help you either. It's a hard task in general - to debug race conditions, not sure why it's brought up. Printing/logging at least is useful as a first step to investigate what's going on at all.