845
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Sep 2024
845 points (100.0% liked)
Programmer Humor
32715 readers
722 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
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.
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().
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.
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
The actual recommended solution is to just read in a loop until you have everything.
Ah yes... several years ago now I was working on a tool called Toxiproxy that (among other things) could slice up the stream chunks into many random small pieces before forwarding them along. It turned out to be very useful for testing applications for this kind of bug.
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 ๐
Had a similar thing at work not long ago.
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.
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).