Einstein did say…
it’s only dumb til it works
And the worst part is when it actually does and you have no fucking idea what went wrong before.
The pc had the hiccups and now it’s fine. Problem solved!
could be a race condition
Hmm…you may be right. I’ll get my Hispanic friend to run it and see if he gets the same result.
It works on my machine
ok, then we ship your machine.
Removed by mod
Just had that happen to me today. Setup logging statements and reran the job, and it ran successfully.
I’ve had that happen, the logging statements stopped a race condition. After I removed them it came back…
Thank you for playing Wing Commander!
That’s step zero: rule out black magic
Those damn cosmic rays flipping my bits
I wonder if there’s an available OS that parity checks every operation, analogous to what’s planned for Quantum computers.
Unrelated, but the other day I read that the main computer for core calculation in Fukushima’s nuclear plant used to run a very old CPU with 4 cores. All calculations are done in each core, and the result must be exactly the same. If one of them was different, they knew there was a bit flip, and can discard that one calculation for that one core.
Interesting. I wonder why they didn’t just move it to somewhere with less radiation? And clearly, they have another more trustworthy machine doing the checking somehow. A self-correcting OS would have to parity check it’s parity checks somehow, which I’m sure is possible, but would be kind of novel.
In a really ugly environment, you might have to abandon semiconductors entirely, and go back to vacuum as the magical medium, since it’s radiation proof (false vacuum apocalypse aside). You could make a nuvistor integrated “chip” which could do the same stuff; the biggest challenge would be maintaining enough emissions from the tiny and quickly-cooling cathodes.
That feeling when it is, in fact, computer ghosts.
The first is a surprise; the second is testing.
======== 37/37 tests passing ========Great time to find out your tests are useless!
So how do you write a good test? It’s like you have to account for unknown unknowns, and I don’t really have a good theory for doing that.
Right now, I usually end up writing tests after the code is broken, and most of them pass because they make the same mistakes as my original code.
They’re not completely useless. They’re conditionally useless, and we don’t know the condition yet.
That’s when the real debug session begins
My way: wrap it in a shell script and put a condition if exit status is not 0 then say “try clear the cache and run it again”
The definition of insanity is doing the same thing over and over and expecting different results.
Yeah, but sometimes it works.
Mmm, race conditions, just like mama used to make.
It’s even worse then: that means it’s probably a race condition and do you really want to run the risk of having it randomly fail in Production or during an important presentation? Also race conditions generally are way harder to figure out and fix that the more “reliable” kind of bug.
There was that kind of bug in Linux and a person restarted it idk how much (iirc around 2k times) just to debug it.
Legit happens without a race condition if you’ve improperly linked libraries that need to be built in a specific order. I’ve seen more than one solution that needed to be run multiple times, or built project by project, in order to work.
Isn’t that the definition of a race condition, though? In this case, the builds are racing and your success is tied to the builds happening to happen at the right times.
Or do you mean “builds 1 and 2 kick off at the same time, but build 1 fails unless build 2 is done. If you run it twice, build 2 does “no change” and you’re fine”?
Then that’s legit.
Good luck figuring out why it sometimes doesn’t work 🙃
One of my old programs produces a broken build unless you then compile it again.
Some code has bugs.
Some code has ghosts.
i sometimes do that so i can inspect the error messages on a cleared terminal
Sometimes I forget what I was looking for and have to restart the mental loop when doing this.
Ever work?
Disturbingly, yes
All the time. Causes include:
- Test depends on an external system (database, package manager)
- Race conditions
- Failing the test cleared bad state (test expects test data not to be in the system and clears it when it exits)
- Failing test set up unknown prerequisite (Build 2 tests depends on changes in Build 1 but build system built them out of order)
- External forces messing with the test runner (test machine going to sleep or running out of resources)
We call those “flaky tests” and only fail a build if a given test cannot pass after 2 retries. (We also flag the test runs for manual review)
Well, duh! You need to use the right incantations!
Removed by mod
Something something motive force.
