And the worst part is when it actually does and you have no fucking idea what went wrong before.
102 0 ReplyThe pc had the hiccups and now it's fine. Problem solved!
29 0 ReplySome times my game engine needs a wake up run, then an actual run.
7 0 Reply
Blame cosmic rays.
1 0 Reply
That's step zero: rule out black magic
89 0 ReplyThose damn cosmic rays flipping my bits
50 0 ReplyPlease tell me you look skyward, shake your fist and yell damn you!!!!
9 0 ReplyI wonder if there's an available OS that parity checks every operation, analogous to what's planned for Quantum computers.
4 0 Reply
That feeling when it is, in fact, computer ghosts.
13 0 Reply
Me: "Hmm... No... No the code is good, it's the compiler that's wrong."
runs again
69 1 ReplyYeah, but sometimes it works.
54 0 ReplyIt'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.
20 0 ReplyOr it was an issue with code generation, or something in the environment changed.
1 0 Reply
Mmm, race conditions, just like mama used to make.
8 0 ReplyThis is 100% valid when dealing with code generation sometimes and I hate it
6 0 ReplyThere was that kind of bug in Linux and a person restarted it idk how much (iirc around 2k times) just to debug it.
6 0 ReplyLegit 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.
2 0 ReplyIsn'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.
2 0 Reply
The first is a surprise; the second is testing.
34 0 Replycould be a race condition
32 0 ReplyHmm..you may be right. I'll get my Hispanic friend to run it and see if he gets the same result.
61 0 ReplyIt works on my machine
19 0 Reply
i sometimes do that so i can inspect the error messages on a cleared terminal
25 0 ReplySometimes I forget what I was looking for and have to restart the mental loop when doing this.
9 0 Reply
One of my old programs produces a broken build unless you then compile it again.
21 0 Reply======== 37/37 tests passing ========
21 0 ReplyGreat time to find out your tests are useless!
11 0 ReplyThey’re not completely useless. They’re conditionally useless, and we don’t know the condition yet.
4 0 ReplySo 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.
1 0 Reply
That's when the real debug session begins
11 0 Reply
I often do this, but I always hit Ctrl-S before running it again. Shamefully, this probably works about 10% of the time. Does that technically count as changing nothing?
20 0 ReplyThat and a make clean can work wonders.
11 0 ReplyAutosave on focus loss dude.
4 0 Reply
The crazy thing is that sometimes this just works...
19 0 ReplyIf that doesn't work, sometimes your computer just needs a rest. Take the rest of the day off and try it again tomorrow.
19 0 ReplyWell, duh! You need to use the right incantations!
16 0 ReplyJust had that happen to me today. Setup logging statements and reran the job, and it ran successfully.
16 0 ReplyI've had that happen, the logging statements stopped a race condition. After I removed them it came back...
14 0 ReplyThank you for playing Wing Commander!
9 0 Reply
I actually did this earlier today
14 0 ReplyI've only recently joined the dev world and I saw this post in the morning. Late this afternoon I'm doing a deployment that fails, couldn't determine the cause as I'm a noob, before bothering a more senior dev for help I run it again... It worked.
1 0 Reply
it's only dumb til it works
10 0 ReplyThe definition of insanity is doing the same thing over and over and expecting different results.
5 0 ReplySponsored by QA gang. Gotta make sure it's a 5/5 issue and not just a frequent issue
5 0 ReplyGot to make sure it's not one of those phantom failures.
4 0 ReplyMy 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"
4 0 ReplyAKA - the test suites at half the companies I've worked. Except they use a loop with retries as well
1 0 Reply
Einstein did say...
3 0 ReplyWell if it doesn't work once try again if it doesn't work twice or thrice maybe there's a problem. If it works it is resolved ... for now, least effort solution.
1 0 ReplyEver work?
1 0 ReplyAll 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)
5 0 ReplyI mean
maybe
4 0 ReplyNot with code, but i write a lot of LaTeX and that often starts working on second compilation
1 0 Reply
If that doesn’t work, restart it and then try.
1 0 ReplyI only do it because it works!
1 0 Replyon xcode i would say it has a 50% chance of working
1 0 Reply