• deegeese@sopuli.xyz
    link
    fedilink
    arrow-up
    16
    arrow-down
    1
    ·
    1 year ago

    When the issue is only seen after hours of runtime, logging is more practical.

    • Chreutz@lemmy.world
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      I recently had an issue that happens on one out of between ten thousand and a hundred thousand interactions between two embedded processors. Thank god for logging!

      • o11c@programming.dev
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        Even logging can sometimes be enough to hide the heisgenbug.

        Logging to a file descriptor can sometimes be avoided by logging to memory (which for crash-safety includes the possibility of an mmap’ed file, since the kernel will just take care of them as long as the whole system doesn’t go down). But logging from every thread to a single section of memory can also be problematic (even without mutexes, atomics can be expensive and certainly have side-effects) - sometimes you need a separate per-thread log, and combine in the log-reader tool.

      • marcos@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        Well, conditional breakpoints exist.

        But use whatever is easiest. People trying to micromanage how others use computers are the worst. And on the most popular languages by job count, your debuggers isn’t all that more powerful than a well-constructed log anyway. (Hell, the people insisting that others adopt better tools should start with the language.)

    • Omgpwnies
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      Or when the overhead of the debugger causes the issue to never happen