Aren't those almost always race condition bugs? The debugger slows execution, so the bug won't appear when debugging.
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.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.
sometimes it's also bugs caused by optimizations.
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
0xcdcdcdcdon free in debug mode).
Perfect, now you just have to wrap your program inside a debugger in production!
This is where
printfdebugging really shines, ironically.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
printcalls as well. I think I ended up just leaving the print calls, because I suck at async programmingYeah, 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.
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).
Just run your prod env in debug mode! Problem solved.
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 helpYou 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, withnpm buildand then ship and serve the bundle.I just died a little inside. Thank you.
i have absolutely seen multiple projects on github that specifically tell you to do "npm run" as part of deploying it.
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.
This is why we shouldn't ban Critical Race Theory.
Yeah! Nobody uses CRT monitors anymore.
Lazy load exception anyone?
He worked for the gaming site/podcast "Giantbomb" years ago. Pretty sure the image macro is pulled from one of their podcast videos.
I always thought it was Cary Elwes.
Clearly you should just ship it with the debugger and call it a day
Exactly, who would put a rebugged version into production anyway?
That would just be irresponsible we want fewer bugs not more of them!
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.
Fear kepts the bits in line
The term is Heisenbug
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 = xposthe most recent assignment would quash the value ofli_current_xin every instance of that event that was currently executing.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.
"You don't debug embedded" ~my brother, who's been working in embedded for almost 15 years
That's why I work with an extraordinary diligence to avoid making errors from the very start. Debugging is only a measure of last resort.
Haha, heisenbugs, always a fun time.
More seriously, I’d be surprised if this wasn’t a classic race condition
It wasn't :D
See my comments below.Well, technically it was a race condition. Just one between two different programs.
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.
Heisenbugs are the worst. My condolences for being tasked with diagnosing one.
The most cryptic status code I've received is 403: OK, while the entire app fails to load
That means you're not allowed in, and that's OK 😂
Probably should be redirected to a login page or something though 😅
"Shhh, it's okay"
I found the solution, we're running debug builds in prod from now on
Someone has a compiler if statement left somewhere in their code (... probably)
One of the worst words in the English language is "intermittent."
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
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.
Behold, https://rr-project.org/
Ya, fuck legacy aggrid
heisenbug
