The Weirdest Linux Bug Ever Discovered

48 thoughts on “The Weirdest Linux Bug Ever Discovered”

• On today's episode of Teaching Sand To Think Was A Mistake:

• When i read the title I was wondering why a printer would rely on steam's api. Steam does maintenance on tuesdays. It's common for games to load longer or just not work on tuesdays if they heavily rely on steamapi

• There was one time that I was programming in codeIgniter and I was getting an exception. I made some changes on one of the files, it didn't solved it, so I reversed the changes and save, I reloaded the page in order to see if perhaps the exception message is different and it worked. I assume that it was a server side cache bug

• But how does the line "%%CreationDate: (Tue …" put "Tue" at byte 4? Even if the file was compressed, it seems unlikely.

• Back in the early days of computers in offices (circa 1986) I had a fault that caused a pc to recognise its floppy drive only on even numbered dates. So the owner would come to me and report his floppy drive not working and I would put it on my list of things to fix the next day. But the next day it worked fine. Until the day after when it stopped working again. This went on for a week or two until I figured out that the data bit that indicated the date was tied to the bit that indicated if the floppy drive was connected. SO every day that the date changed the existence of the floppy drive alternated. A change of memory chips fixed the problem.

• And this is the reason why normal people avoid linux

• files:
  "Mhmm, another Tuesday. Time to mark printable as Erlang!"

• On Tuesdays, you can only print on Tacos…

• Great video! … but you left us hanging! Did they actually patch the bug? Because now I'm dying to know haha.

• “Steve figured out the bug” ❌
  Steve’s wife figured out the bug ✅

• It's a security problem to identify a file type by inspecting its contents and then acting on them. The file's type should be communicated reliably via some metadata, with the extension being a hacky but standard and workable approach. Mimetypes are better when available. Aside from being a security problem, such identification is fundamentally janky, as this 'bug' demonstrates. It isn't really a bug, it's a heuristic gone wrong.

• It was some man's wife that noticed she couldn't print on a Tuesday. Men don't think like that, only a woman would remember that is was a Tuesday last time it didn't work. Thank you ladies.

• My retired ex-boss told me about the problem in the 80s with backup tapes being faulty during sunny days but only in winter. Apparently in the winter the sun didn't rise as high so it could shine through the window all the way to the tape writer and mess up the writing head. The fix was a strategically placed piece of cardboard.

• I always thought that printers went on vacation the Mondays. The more you know

• A few years ago, i was maintaining what is basically a custom e-commerce platform when i recieve one of these bug : "the search function can't find the article named ******". Specifically, this article. The article exist in DB and is globally the same as every other article next to him. I'm losing my mind over it for a long time and then learn that other article are in the same situation. The test team is starting to compile a whole document with article that can't be find and example of similar article that can be find. I waste days trying to find what make these article special, which data corruption occured.
  When at last i find the dumbest correlation but i have tried everything else. I test it and it is confirmed. For more than 5 years, the platform returned No result for any search containing the letter 'u' .

  (Explanation : the preceding dev team found usefull to manually escape every character of the search field at some point. Which transformed the litteral unescaped u into u the start of a unicode character corrupting the search string before sending it into the request.)

• This is why it almost always makes sense to share libraries in software.
  This is so obviously an integration issue, that could have been prevented, if all drivers and applications communicating with them worked the same.
  No single source made a mistake here, it just doesn't work, because the parts were not meant to be combined in this way.

• Even more wierd — it took another 16 years to make a video on the bug! 🙂

• I mean its not the program does not work on the 30 of any month, or the leap year day on a year whit leap year day.

• 6:35 These are bad examples: here the file type can be deduced from metadata. The real magic happens when it needs to look at the contents

• SW engineers (I am one) often think to quick about a specific root cause and solution of a problem so they are getting blind for the very unusual causes. Maybe it needed a "naiv" user like the engineer's wife to see the pattern and saying it out loud.

• after i skipped the ad it just spins

• This is "can't send emails more than 500 miles" level of absurd

• If I left my Range Rover in the garage over the weekend (Saturday and Sunday) it would have a very low battery on Monday! If left in the service garage over the weekend, nothing odd was detected. After a few weekends, I suggested they bring their diagnostic equipment over and test it in my garage. They discovered the issue within 15 minutes. The reason was because the neighbour was a radio amateur and usually blasted the airwaves every weekend, causing the Rangie to continuously wake up and go back to sleep each time he pressed to talk, eventually draining the battery! The Rangie had a RFI issue and he had a faulty antenna causing a side lobe directed at my garage! Fix was to earth his antenna tower.

• "Unless it's dark outside."

• This infuriates me.

• It was fixed, right?

• I'm gonna say it was a skill issue.

• I bet they did fix on a Tuesday… since every Trekkie knows it will be fixed on Tuesday… 🙂

• I always go back to an issue that I had when I was a teenager, playing on windows in LAN. There was a faulty connection in one of our ethernet cables, so we kept having disconnections, but when we changed the cable to another cable that should work, but didn't. We assumed that we'd checked the cable, and thus kept trying everything else. Many days later, you get the idea to check the cable just because, and find the issue. Issues where you've already checked for them, and they should not be there, but still are. You kind of need a lot of experience to get into a mindset where you can say to yourself that you ought to check that cable again, or you ought to check for that insane possibility, that actually is the case. Bugs like this are terrible, and hard to replicate, and I feel for the users who were dealing with the issue back then.

• Can't believe I've been in testing for over almost 2 decades and never heard about this!

• I will never feel safe on tuesdays again.

• Suddenly a lot of tests failed at work, couldn't find out why since it didn't seem to have anything to do with the code I was modifying. Finally figured out that the tests used dates in weird ways and those ways didn't work in February…

• 😂 lol I kind of have a feeling I was affected by this. I remember chassing a printer issue that just wouldn't go away, but also wouldn't stay arround to get looked at properly, when I had time. But it also just be my brain lying to me. So long agoq😅

• The weirdest Linux bug was an off by one error in the terminal login, when trying to login and typing a wrong password twice, it would not accept the third try even if the typed password was correct that time. This bug was there for many years, I myself found it years before it was fixed but I never reported it, because it rarely happened that you typed your password wrong two times in a row, so I didn't care enough to report it.

• I once had a bug which only manifested when we stripped the gdb debug symbols from the binary. Turns out it was a struct packing / byte boundary alignment problem. Ofc finding it was a bitch because you couldn't use gdb to identify it lol.

• I have a super strange bug in Autodesk Maya. I seem to fail to get others interested in it but for me its on the level of this one.

  There's a sequence of key presses I can do that will 100% guaranteed to crash the program when I do it. This has worked across versions, across different devices, I can (could) replicate it anywhere. Haven't used Maya in a while though.

  Here's the interesting part: If I instruct someome else to do the same sequence, on the same device as me, in the same version, it did not crash. I worked at an animation studio at the time and we did a couple of experiments across various machines. Slow, deliberate input, everything. Crashed at home as well. Years later I was working in a different country and it still crashed for me. The annoying part is that the sequence is just a distilled version of something that can happen normally at work, so I would encounter this crash regulary.
  This bug is attached to me, personally. I call it the curse of the Maya.
  IIRC there was one other coworker or something for whom the bug worked as well. Either way, its person dependent, and machine and version independent. 100% rate of replication for me. Not for others.
  I made a post on stackexchange about it at the time but no one took interest.

  IIRC the sequence goes as follows:
  Open Maya – Spawn a Cylinder – Select the cylinder, use the space bar to switch views to one of the side views which is in wireframe mode – edit the geometry there, press 3 to go into smooth geometry preview, press space to leave the view – Full crash.
  The essense of the bug is switching to smooth geometry preview (Keyboard Shortcut "3") on a wireframe view and then switching views.
  Which is a thing that one may do without second thought while modeling.
  Only crashes for me. Or a select few.
  Always crashes for me, and those select few.
  I mean, these days I use blender. But I am fascinated by this bug

  Whenever I see a machine with maya on it I try it out. Last time is already a couple years back though. First discovered in 2016 or something, last time I tried (still crashing) was 2022 I believe, latest version then.

• Okay but we're missing the real reason this was such an issue. An error clearly occurred, but it was not passed back to the calling application to be handled, which made it harder to trace.

• i discovered a similar bug with akkoma not that long ago
  on an old version that my friend was running it was using localized names in strftime when making a request to register an account move to another instance and since you can only use ascii in http headers(it was putting it in Date) and the server was running with polish locale and the only day of the week in polish that has non-ascii characters in its shortened form is Wednesday(Śr) it didnt work on wednesdays

• "These are software bugs that seem to disappear when one attempts to study them."
  Quantum bug-fixing is hard 💀💀

• 5:14 – Someone worked it out. A guy by the name of Steve.
  Steve: My wife has complained that OOo will never print of Tuesdays.

• Something else to ask: does this also happen for other language settings ????

• So why did File look for Tue? And why does that identify something as an Erlang file?

• Quoting another Youtuber: "Is Drifloon the Friday Pokemon?"

• The printer is a "Beech"

• chewsday

• Once spent six months chasing an explicit Tuesday bug around and around. Someone (won't name names or point fingers) had created a test for a "TWOFER TUESDAY!" feature. The test, naturally, failed on Tuesdays. The QA guy kept testing on Tuesday.

  That bastard.

• Chewsday

• Person: Hey printer, can you print out this document?
  Printer: Can't…
  Person: Why not? I refilled your ink and I know you have paper.
  Printer: It's Tuesday.

Comments are closed.