• Quacksalber@sh.itjust.works
    link
    fedilink
    arrow-up
    3
    ·
    2 months ago

    Aren’t those almost always race condition bugs? The debugger slows execution, so the bug won’t appear when debugging.

    • BlueKey@fedia.ioOP
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      Turned out that the bug ocurred randomly. The first tries I just had the “luck” that it only happened when the breakpoints were on.
      Fixed it by now btw.

      • dunz@feddit.nu
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        I had a bug like that today . A system showed 404, but about 50% of the time. Turns out I had two vhosts with the same name, and it hit them roughly evenly 😃

        • BlueKey@fedia.ioOP
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          I’m new to Go and wanted to copy some text-data from a stream into the outputstream of the HTTP response. I was copying the data to and from a []byte with a single Read() and Write() call and expexted everything to be copied as the buffer is always the size of the while data. Turns out Read() sometimes fills the whole buffer and sometimes don’t.
          Now I’m using io.Copy().

      • xthexder@l.sw0.com
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        And that’s where Release with debug symbols comes in. Definitely harder to track down what’s going on when it skips 10 lines of code in one step though. Usually my code ends up the other way though, because debug mode has extra assertions to catch things like uninitialized memory or access-after-free (I think specifically MSVC sets memory to 0xcdcdcdcd on free in debug mode).