853
top 50 comments
sorted by: hot top controversial new old
[-] rain_worl@lemmy.world 0 points 1 day ago
[-] Quacksalber@sh.itjust.works 155 points 1 month ago

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

[-] BlueKey@fedia.io 82 points 1 month 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.

[-] Skullgrid@lemmy.world 92 points 1 month ago

bug ocurred randomly.

Fixed it by now btw.

someone's not sharing the actual root cause.

[-] BlueKey@fedia.io 60 points 1 month 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().

[-] dfyx@lemmy.helios42.de 51 points 1 month ago

Note that this isn't specific to Go. Reading from stream-like data, be it TCP connections, files or whatever always comes with the risk that not all data is present in the local buffer yet. The vast majority of read operations returns the number of bytes that could be read and you should call them in a loop. Same of write operations actually, if you're writing to a stream-like object as the write buffers may be smaller than what you're trying to write.

[-] bl_r@lemmy.dbzer0.com 13 points 1 month ago

I’ve run into the same problem with an API server I wrote in rust. I noticed this bug 5 minutes before a demo and panicked, but fixed it with a 1 second sleep. Eventually, I implemented a more permanent fix by changing the simplistic io calls to ones better designed for streams

[-] dfyx@lemmy.helios42.de 7 points 1 month ago

The actual recommended solution is to just read in a loop until you have everything.

load more comments (1 replies)
[-] dunz@feddit.nu 17 points 1 month 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 😃

load more comments (1 replies)
[-] ExtraMedicated@lemmy.world 12 points 1 month ago

I had one years ago with internet explorer that ended up being because "console.log" was not defined in that browser unless you had the console window open. That was fun to troublshoot.

[-] anhkagi@jlai.lu 9 points 1 month ago

sometimes it's also bugs caused by optimizations.

load more comments (1 replies)
[-] ambitiousslab@lemmy.ml 76 points 1 month ago

Perfect, now you just have to wrap your program inside a debugger in production!

[-] henfredemars@infosec.pub 47 points 1 month ago* (last edited 1 month ago)

We test AND develop in production. Get on my level.

[-] leisesprecher@feddit.org 36 points 1 month 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.pub 13 points 1 month 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.

load more comments (1 replies)
[-] bhamlin@lemmy.world 55 points 1 month ago

This is where printf debugging really shines, ironically.

[-] meekah@lemmy.world 12 points 1 month 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

load more comments (1 replies)
[-] dejected_warp_core@lemmy.world 5 points 1 month ago* (last edited 1 month 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 "printf debugging" like this is truly your best bet.

To 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).

[-] TheSlad@sh.itjust.works 48 points 1 month ago

Just run your prod env in debug mode! Problem solved.

[-] lupec@lemm.ee 28 points 1 month 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~~

[-] Barbarian@sh.itjust.works 12 points 1 month 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.

load more comments (1 replies)
load more comments (2 replies)
[-] MultipleAnimals@sopuli.xyz 25 points 1 month ago* (last edited 1 month 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.

[-] AlecSadler@sh.itjust.works 14 points 1 month ago

I just died a little inside. Thank you.

[-] Swedneck@discuss.tchncs.de 11 points 1 month ago

i have absolutely seen multiple projects on github that specifically tell you to do "npm run" as part of deploying it.

[-] Aceticon@lemmy.world 47 points 1 month 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.

[-] Psythik@lemmy.world 24 points 1 month ago

This is why we shouldn't ban Critical Race Theory.

Yeah! Nobody uses CRT monitors anymore.

load more comments (1 replies)
[-] brbposting@sh.itjust.works 42 points 1 month ago
[-] mosiacmango@lemm.ee 18 points 1 month ago* (last edited 1 month ago)

He worked for the gaming site/podcast "Giantbomb" years ago. Pretty sure the image macro is pulled from one of their podcast videos.

[-] WhiskyTangoFoxtrot@lemmy.world 6 points 1 month ago

I always thought it was Cary Elwes.

[-] chad@sh.itjust.works 25 points 1 month ago* (last edited 1 month 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.pub 13 points 1 month ago* (last edited 1 month 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.

[-] flashgnash@lemm.ee 24 points 1 month ago

Clearly you should just ship it with the debugger and call it a day

[-] phorq@lemmy.ml 10 points 1 month ago

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

load more comments (1 replies)
[-] Steamymoomilk@sh.itjust.works 23 points 1 month ago

Fear kepts the bits in line

[-] airbreather@lemmy.world 17 points 1 month ago
[-] vithigar@lemmy.ca 13 points 1 month ago

For those of you who've never experienced the joy of PowerBuilder, this could often happen in their IDE due to debug mode actually altering the state of some variables.

More specifically, if you watched a variable or property then it would be initialised to a default value by the debugger if it didn't already exist, so any errors that were happening due to null values/references would just magically stop.

Another fun one that made debugging difficult, "local" scoping is shared between multiple instances of the same event. So if you had, say, a mouse move event that fired ten times as the cursor transited a row and in that event you set something like integer li_current_x = xpos the most recent assignment would quash the value of li_current_x in every instance of that event that was currently executing.

[-] Treczoks@lemmy.world 11 points 1 month ago

Heisenbug. Nasty buggers, especially in my domain: Embedded Engineering. When you are in the debugger, the whole processor is stopped, missing tons of data coming in, missing interrupts, getting network timeouts, etc. More often than not, resuming makes no sense, and you have to get straight to reboot.

[-] fiqusonnick@lemmy.blahaj.zone 6 points 1 month ago

"You don't debug embedded" ~my brother, who's been working in embedded for almost 15 years

load more comments (1 replies)

Haha, heisenbugs, always a fun time.

More seriously, I’d be surprised if this wasn’t a classic race condition

load more comments (2 replies)
[-] dejected_warp_core@lemmy.world 8 points 1 month ago

Heisenbugs are the worst. My condolences for being tasked with diagnosing one.

[-] whoisearth@lemmy.ca 8 points 1 month 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.

[-] tiefling@lemmy.blahaj.zone 7 points 1 month ago

The most cryptic status code I've received is 403: OK, while the entire app fails to load

[-] Venat0r@lemmy.world 4 points 1 month ago* (last edited 1 month ago)

That means you're not allowed in, and that's OK 😂

Probably should be redirected to a login page or something though 😅

load more comments (1 replies)
[-] mvirts@lemmy.world 6 points 1 month ago

I found the solution, we're running debug builds in prod from now on

[-] mindbleach@sh.itjust.works 5 points 1 month ago

One of the worst words in the English language is "intermittent."

[-] uranibaba@lemmy.world 4 points 1 month 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.

[-] answersplease77@lemmy.world 4 points 1 month ago

this happens with so many scripts I've tried to debug with strace because strace requires to run as root or sudo which elevates the niceness of process which prevents certain errors from occuring when the script is run with root permissions and so it runs flawlessly without bugs and you sit wondering wtf

[-] Nighed@sffa.community 4 points 1 month ago

Someone has a compiler if statement left somewhere in their code (... probably)

load more comments
view more: next ›
this post was submitted on 03 Sep 2024
853 points (99.5% liked)

Programmer Humor

32225 readers
725 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS