• phorq@lemmy.mlEspañol
      0·
      4 months ago

      Exactly, who would put a rebugged version into production anyway?

  • chad@sh.itjust.works
    0·
    4 months ago

    I’m a contractor at a rocket launch service provider. The final build of the ground control software is compiled and deployed to the launch pad with debug flags enabled because of a “fly like you test” mandate.

    Millions of dollars and tons of time invested by brilliant people are riding on rockets that are launched using software with debug flags because of an “if it ain’t broke don’t fix it” mentality and archaic test strategies.

    • henfredemars@infosec.pubEnglish
      0·
      4 months ago

      I’ve worked on ground systems and it’s actually come in handy two times in five years, usually where we had a hard-to-reproduce bug. Getting the info when the problem happens can occasionally be all the difference.

      Addendum: And usually we didn’t care about performance. Basically never.

    • silly goose meekah@lemmy.world
      0·
      4 months ago

      I once had a racing condition that got tipped over by the debugger. So similar behavior to what’s in the meme, but the code started working once I put in the print calls as well. I think I ended up just leaving the print calls, because I suck at async programming

      • Buddahriffic@lemmy.world
        0·
        4 months ago

        Yeah, I was going to mention race conditions as soon as I saw the parent comment. Though I’d guess most cases where the debugger “fixes” the issue while print statements don’t are also race conditions, just the race isn’t tight enough that that extra IO time changes the result.

        Best way to be thorough with concurrency testing IMO involves using synchronization to deliberately check the results of each potential race going either way. Of course, this is an exponential problem if you really want to be thorough (like some races could be based on thread 1 getting one specific instruction in between two specific instructions in thread 2, or maybe a race involves more than 2 threads, which would make it exponentially grow the exponential problem).

        But a trick for print statement debugging race conditions is to keep your message short. Even better if you can just send a dword to some fast logger asynchronously (though be careful to not introduce more race conditions with this!).

        This is one of the reasons why concurrency is hard even for those who understand it well.

    • dejected_warp_core@lemmy.world
      0·
      4 months ago

      Honestly, this is why I tell developers that work with/for me to build in logging, day one. Not only will you always have clarity in every environment, but you won’t run into cases where adding logging later makes races/deadlocks “go away mysteriously.” A lot of the time, attaching a debugger to stuff in production isn’t going to fly, so truly “printf debugging” like this is truly your best bet.

      To truly do this right, look into logging modules/libraries that support filtering, lazy evaluation, contexts, and JSON output for perfect SEIM compatibility (enterprise stuff like Splunk or ELK).

  • whoisearth@lemmy.ca
    0·
    4 months ago

    When I write APIs I like to set endpoints to return all status codes this way no matter what you’re doing you can always be confident you’re getting the expected status code.

  • Aceticon@lemmy.world
    0·
    4 months ago

    Sound like a critical race condition or bad memory access (this latter only in languages with pointers).

    Since it’s HTTP(S) and judging by the average developer experience in the domain of multi-threading I’ve seen even for people doing stuff that naturally tends to involve multiple threads (such as networked access by multiple simultaneous clients), my bet is the former.

    PS: Yeah, I know it’s a joke, but I made the serious point anyways because it might be useful for somebody.

  • uranibaba@lemmy.world
    0·
    4 months ago

    I once had a bug in a C# program I wrote. It made a HTTP request and if the user agent was left to default (whatever that was), the server just gave back an empty string as a reply. I took way to long until I understood what was going on and I kept chasing async, thinking I had messed it up some how.

    • Lupec@lemm.ee
      0·
      4 months ago

      Lol my workplace ships Angular in debug mode. Don’t worry though, the whole page kills itself if a dubious third-party library detects the console is open. Very secure and not brittle at all! Please send help

        • SteveTech@programming.devEnglish
          0·
          4 months ago

          I’ve seen some that activate an insane number of breakpoints, so that the page freezes when the dev tools open. Although Firefox let’s you disable breaking on breakpoints all together, so it only really stops those that don’t know what they’re doing.

      • Barbarian@sh.itjust.works
        0·
        4 months ago

        Blink-blink-blink. Blink. Blink. Blink. Blink-blink-blink.

        No, I don’t have something in my eyes, I swear I’m fine looks nervously at boss.

    • MultipleAnimals@sopuli.xyz
      0·
      4 months ago

      You can imagine how many node projects there are running in production with npm run. I have encountered js/ts/node devs that don’t even know that you should like, build your project, with npm build and then ship and serve the bundle.

      • leisesprecher@feddit.org
        0·
        4 months ago

        One of our customers does that. It happened multiple times already that one dev fixed an issue in production, and the next regular deployment overwrote everything.

        But fortunately, it’s just critical infrastructure and nothing important.

        • henfredemars@infosec.pubEnglish
          0·
          4 months ago

          When I left my last job they were using the zip file method for version control and one creative developer managed to link two versions of libc at the same time.

          Software is so useful that the standard for utility is extremely low.