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.bug ocurred randomly.
Fixed it by now btw.
someone’s not sharing the actual root cause.
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().
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 😃
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!
We test AND develop in production. Get on my level.
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.
The most cryptic status code I’ve received is 403: OK, while the entire app fails to load
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
This is where
printfdebugging really shines, ironically.Heisenbugs are the worst. My condolences for being tasked with diagnosing one.
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 helpBlink-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.
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, withnpm buildand then ship and serve the bundle.i have absolutely seen multiple projects on github that specifically tell you to do “npm run” as part of deploying it.
I just died a little inside. Thank you.
heisenbug
