What’s the weirdest software bug you’ve encountered?

AllThingsTech

Well-known member
Joined
8 Jun 2025
Messages
225 (8.65/day)
I can tell you mine:
I was on a call to a friend on Discord. It was clear that my audio delivery to him was being delayed. Note that it was a video call so it was clear that he was receiving my (audio) messages late, So, here goes:
  • Friend says “sorry about that”.
  • I ask what he’s apologising for.
  • It looks like he’s ignoring me.
  • Friend activates a power-up in a game and giggles at me as I get trolled and lose.
  • I jab at him “stop giggling at my suffering!”
  • It looks like he’s ignoring me.
  • I ask “can you hear me?”
  • It looks like he can’t hear me.
  • 15 minutes later, friend says “What are you talking about? I never apologised. You also said I’m giggling, you can see that I’m not. What are you talking about?” And then he gave me a “Yes, I can hear you” x3
The convo was soooo out of context it was bloody hilarious 😂😂😂

We have an inside joke that Discord lime to strikes up Discord. Here goes another more irritating one there Discord went as far as initaiting a fallout:
  • I see on Discord I’m not “friends” with my friend.
  • I attempt to message him and I receive a “message not received” error.
  • I attempt to call him and I receive a “call failed” error.
  • I message friend “Why have you blocked me?”
  • Friend takes offence to my assumption.
  • Then, I notice I’ve been “unfriended by everyone”.
  • I refresh the Discord app and see everything has besn resolved.
So, what’s the weirdest software bug you’ve encountered?
I’d love to hear some interesting/quirky/funny/silly/annoying/disastrous stories !
 

AllThingsTech

Well-known member
Joined
8 Jun 2025
Messages
225 (8.65/day)
@petermarkley as you’re a programmer, as per your profile, just like me, this may interest you!

Just felt like putting out a random thought: customers are often quick to place blame whenever a software bug occurs, not recognising all the hard work and effort required in software engineering. Keen to hear thoughts 😎
 

petermarkley

Well-known member
Joined
7 Sep 2024
Messages
81 (0.27/day)
Memory leaks in a C program can be downright spooky, like causing different behavior with exact same inputs. I’ve dealt with those before for example on this project, but it’s been a very long time and I can’t recall the details now.

Of course, there’s always the adventurous and exotic crashes one gets when using Open Source software, like this bug report I filed for Inkscape a few years ago.

Those are what comes to mind for the moment … I’ll probably think of better examples later 🙂
 

Retro

Founder
Staff Member
Joined
4 Jun 2021
Messages
6,756 (4.53/day)
Location
UK
Oh, I've got a good one, people.

It's 1989 and back in those days, I was dabbling with ARM assembler on my new Acorn A3000 with 2MB RAM. This ARM2 based PC beat the pants off the PCs of the day, it was so fast.

ARM assembler was integrated into the BBC BASIC it came with in ROM, so you could write ARM code without loading any apps, quite the unique feature to all Acorn computers since the BBC Micro, perhaps the Atom before it. You just set up a header, memory block, an entry point and away you went. And I loved it. That assembler was so damned fast, too. Anyway, I wrote some small, fast and efficient ARM routine that I felt quite impressed with. Sorry, I forget what it did now after 36 years, but I do remember that I loved programming that elegant RISC processor.

What an awesome architecture, it was like nothing I'd used before it. The only RISC CPUs that existed before it were in high end SUN SPARC workstations of the day that cost many thousands of pounds and totally out of the reach of mere mortals like me. My A3000 was "just" £749, not a small amount by any means, but affordable for the masses, more or less.

That week, I went to the computer club, clutching the floppy disc I'd saved it on with the intention of impressing the resident genius programmer there. And I mean, this guy was really clever, perhaps even an actual genius, but he was never big headed about it, being one of the nicest people you could meet, always helping out lesser mortals like me and was very sociable. He didn't fit the nerdy socially awkward stereotype at all. I do remember that he was unusually tall and skinny though, towering over everyone in the room. I'll call him Dave, not his real name.

I proudly ran the BASIC program which assembled and ran the machine code and...

It bombed out with some stupid, fucking, error and no way would it work! :mad: It was borked, good and proper. 😭

I started troubleshooting it. The program wasn't corrupted due to a bad disc and his Acorn Archimedes 310 with 4MB RAM wasn't faulty either. No, something was wrong with my program, but what???! I spent most of that evening hogging poor Dave's Archimedes trying to find the bug in it that caused this crash, but no dice. He eventually wanted his computer back to do the stuff that he'd brought it over for, something really clever, naturally. Thankfully he was nice about it and didn't humiliate me about this cockup, although I was there already, believe me, and extremely frustrated. Heck, I still feel it now when I think about it. He offered to help troubleshoot it for me, but my pride got in the way, so I'd find it or nothing.

I got nothing.

The code looked just fine and I left that meet really frustrated.

At this point dear reader, do you have an inkling of where the problem was yet? 😉 There's a clue in the preceding description.

Right, so I got home, put the floppy disc in my A3000 and lo and behold it worked again! Fixed! 😃 No, of course not as I hadn't modified that code on the disc at all. For good measure, I even loaded the original off the original floppy disc, but the code was identical.

I kept looking and looking and looking at that program, the whole code, including the BASIC setup section and then it finally dawned on me: his PC had 4MB RAM while mine had 2MB. This meant that the memory page size in the TLB on his was double the size of mine, but that still shouldn't have caused a problem. There was nothing wrong with the assembly code. What was borked was the header setup for it in the BASIC part. Somehow, I'd made a tiny syntax error in it which resulted in valid BASIC code so there was no runtime error from the interpreter, but scrambled the memory allocation for the machine code, which somehow still happened to work on a 2MB machine, but not a 4MB one. 🤦‍♂️ It was a real simple typo too, like transposing a couple of characters, which I fixed. Again, I don't remember the details after all this time

I eventually upgraded my A3000 to 4MB, the maximum possible, and yes, the fixed program worked while the original didn't, confirming my diagnosis.

Unfortunately, I never got to demo my program to Dave as he didn't always bring his PC down to the club and I wasn't always there, either. I did describe what the code did though and he did think it was decent. Remember, there was no internet, no websites and no email back then. These only existed in a primitive form still being developed in universities and military labs.

I still have that computer and likely the floppy discs I'd stored that program on. Whether those discs still work is another matter though. The power supply likely needs recapping by now, too. It's not been switched on for years.

I didn't have a HDD at the time as they were an expensive luxury back then, so everything was on floppy discs. Unthinkable now in the days of superfast M.2 SSDs, eh?

This is my Acorn A3000:
 

AllThingsTech

Well-known member
Joined
8 Jun 2025
Messages
225 (8.65/day)
Memory leaks in a C program can be downright spooky, like causing different behavior with exact same inputs. I’ve dealt with those before for example on this project, but it’s been a very long time and I can’t recall the details now.

Of course, there’s always the adventurous and exotic crashes one gets when using Open Source software, like this bug report I filed for Inkscape a few years ago.

Those are what comes to mind for the moment … I’ll probably think of better examples later 🙂
Woah, C can be pretty dangerous!!! And I imagine that debugging to find the root cause of a bug isn’t always easy, either, though one improves with experience!

Oh, I've got a good one, people.

It's 1989 and back in those days, I was dabbling with ARM assembler on my new Acorn A3000 with 2MB RAM. This ARM2 based PC beat the pants off the PCs of the day, it was so fast.

ARM assembler was integrated into the BBC BASIC it came with in ROM, so you could write ARM code without loading any apps, quite the unique feature to all Acorn computers since the BBC Micro, perhaps the Atom before it. You just set up a header, memory block, an entry point and away you went. And I loved it. That assembler was so damned fast, too. Anyway, I wrote some small, fast and efficient ARM routine that I felt quite impressed with. Sorry, I forget what it did now after 36 years, but I do remember that I loved programming that elegant RISC processor.

What an awesome architecture, it was like nothing I'd used before it. The only RISC CPUs that existed before it were in high end SUN SPARC workstations of the day that cost many thousands of pounds and totally out of the reach of mere mortals like me. My A3000 was "just" £749, not a small amount by any means, but affordable for the masses, more or less.

That week, I went to the computer club, clutching the floppy disc I'd saved it on with the intention of impressing the resident genius programmer there. And I mean, this guy was really clever, perhaps even an actual genius, but he was never big headed about it, being one of the nicest people you could meet, always helping out lesser mortals like me and was very sociable. He didn't fit the nerdy socially awkward stereotype at all. I do remember that he was unusually tall and skinny though, towering over everyone in the room. I'll call him Dave, not his real name.

I proudly ran the BASIC program which assembled and ran the machine code and...

It bombed out with some stupid, fucking, error and no way would it work! :mad: It was borked, good and proper. 😭

I started troubleshooting it. The program wasn't corrupted due to a bad disc and his Acorn Archimedes 310 with 4MB RAM wasn't faulty either. No, something was wrong with my program, but what???! I spent most of that evening hogging poor Dave's Archimedes trying to find the bug in it that caused this crash, but no dice. He eventually wanted his computer back to do the stuff that he'd brought it over for, something really clever, naturally. Thankfully he was nice about it and didn't humiliate me about this cockup, although I was there already, believe me, and extremely frustrated. Heck, I still feel it now when I think about it. He offered to help troubleshoot it for me, but my pride got in the way, so I'd find it or nothing.

I got nothing.

The code looked just fine and I left that meet really frustrated.

At this point dear reader, do you have an inkling of where the problem was yet? 😉 There's a clue in the preceding description.

Right, so I got home, put the floppy disc in my A3000 and lo and behold it worked again! Fixed! 😃 No, of course not as I hadn't modified that code on the disc at all. For good measure, I even loaded the original off the original floppy disc, but the code was identical.

I kept looking and looking and looking at that program, the whole code, including the BASIC setup section and then it finally dawned on me: his PC had 4MB RAM while mine had 2MB. This meant that the memory page size in the TLB on his was double the size of mine, but that still shouldn't have caused a problem. There was nothing wrong with the assembly code. What was borked was the header setup for it in the BASIC part. Somehow, I'd made a tiny syntax error in it which resulted in valid BASIC code so there was no runtime error from the interpreter, but scrambled the memory allocation for the machine code, which somehow still happened to work on a 2MB machine, but not a 4MB one. 🤦‍♂️ It was a real simple typo too, like transposing a couple of characters, which I fixed. Again, I don't remember the details after all this time

I eventually upgraded my A3000 to 4MB, the maximum possible, and yes, the fixed program worked while the original didn't, confirming my diagnosis.

Unfortunately, I never got to demo my program to Dave as he didn't always bring his PC down to the club and I wasn't always there, either. I did describe what the code did though and he did think it was decent. Remember, there was no internet, no websites and no email back then. These only existed in a primitive form still being developed in universities and military labs.

I still have that computer and likely the floppy discs I'd stored that program on. Whether those discs still work is another matter though. The power supply likely needs recapping by now, too. It's not been switched on for years.

I didn't have a HDD at the time as they were an expensive luxury back then, so everything was on floppy discs. Unthinkable now in the days of superfast M.2 SSDs, eh?

This is my Acorn A3000:
Wow Retro, impressive that you code in assembly! We did a course on assembly programming at university, and it fried my brain! And this was primarily because the assembly language chosen is not the most popular and so less community support exists. I believe this was done intentionally to force us to apply our problem-solving skills. Irrespective, assembly language is not the easiest to understand and work with, I tell you!

Have you tried a high level programming language, and how do you find it compared to assembly? Programming in general is almost second nature to me, but I feel like assembly would fry my brain no matter what! So much to consider all at once!
 

petermarkley

Well-known member
Joined
7 Sep 2024
Messages
81 (0.27/day)
I imagine that debugging to find the root cause of a bug isn’t always easy, either, though one improves with experience!
Very true. They can manifest as so-called “Heisenbugs,” which are very nasty to deal with. Of course, once you know that a Heisenberg is usually a dead giveaway for a memory management issue, it becomes a needle-haystack problem of finding your mistake using the spooky non-correlating evidence. There are debug tools to help, like Valgrind, but it can still be a pain.

I have found and fixed dozens of these in my time, and for me they have almost always been very basic typos, sometimes with just a single character, that cause for example buffer overflow and scribbling on unintended bits of memory. It also depends on how fancy you’re trying to get with the memory: are you just using and resizing a flat buffer, or is it a linked list with a complex hierarchy? Etc. One key is to keep your logic tight: for every single call to calloc() or similar, make sure there is a corresponding and appropriately invoked call to free(), no matter how big and complicated the scheme gets for how you use that memory.

To help with this on the aforementioned Libmcmap project, my dad and I went as far as writing an external tracking system that literally replaced the function symbols for calloc() and free() so that we could perform our own audits, find mistakes, and ultimately build confidence in the program’s durability. This work can be found in the memdb files in that project. Getting that clean report at the end was a beautiful thing ☺️

what’s the hardest software bug you’ve ever had to fix?
I suppose the above could suffice to answer that. Having trouble thinking of a better answer
 
Last edited:
Back
Top Bottom