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.
In the northwest, esp Liverpool, they were always called “scallies”. Don’t know about today though.
First came across the term “chav” in the midlands.
In London “roadman” doesn’t seem to be exactly the same thing. Seems to be more of an act by kids trying to fit in or look hard. “Scallies” were less about their front and more about the skinheads and tracksuits which was as much an income thing as anything else.
“Chavs” just seems to imply tastlessness. The fake tan orange girls w attitude problems, belligerent guys in a labelled shirt getting into boozy fights etc. There’s a lot of cross over, but I don’t think they’re identical.
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.
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
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.
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.
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.
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).
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'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 😃
A newly deployed version of a component in our system was only partially working, and the failures seemed to be random. It’s a distributed system, so the error could be in many places. After reading the logs for a while I realized that only some messages were coming through (via a message queue) to this component, which made no sense. The old version (on a different server) had been stopped, I had verified it myself days earlier.
Turns out that the server with the old version had been rebooted in the meantime, therefore the old component had started running again, and was listening to the same message queue! So it was fairly random which one actually received each message in the queue 😂
Problem solved by stopping the old container again and removing it completely so it wouldn’t start again at the next boot.
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.
fedia.io
Newest