This story is a beautiful example of such a story. Great read, great bug, great analysis!
Years ago I worked on a stock control system for a popular clothes retailer. Where previously store managers had to spend hours on the phone ringing the depots to see what was in stock and reordering popular lines, now they could fill in orders an they would be emailed to the depots in machine readable format, with the order balanced across multiple depots depending on availability of stock.
After the system had been in operation for a year or so, managers started to complain that some orders weren’t turning up. After a bit of digging it only seemed to affect one particular depot, but I couldn’t initially see a common factor between the orders. It had nothing to do with the size of the mail, or the originating store. I could tell from the logs the emails were being formatted and supposedly sent to the depot, yet they never translated into orders. The system would silently fail after we’d handed the email to the depot with no obvious reason why.
So I wrote a quick script to collect all the orders for a day from all the stores and compile a list of all product lines that were present in the orders that went missing, but not present in the orders that succeeded, just to see if there was a pattern. This turned up a few dozen items and after a quick visual scan of the product descriptions one stood out slightly, so I phoned the depot on a hunch.
The depot had an anti-spam filter on incoming emails that silently dropped messages with pornographic words in the body or any attachments. The retailer had just received a new seasonal product line, which was selling well, and the product description was “bondage tights”.
After getting the depot to whitelist emails from our system, orders for this product line started working.
PayPal refused to admit to us that this was the cause and insisted they couldn't shed any further light on the issue despite the fact we could trigger it 100% of the time.
In the last few weeks it's started randomly choking on the word "Pharaoh", God knows why, and God knows why it only does so about half the time, but I'm not going to bother asking PayPal about it.
But yeah, it sucks that their system can't learn to give you an exception after it has been reviewed once or twice.
(last seen in Hungary, likely being involved with the prime minister; there was some scandal about it)
We seem to condition ourselves to quickly forget the excitement because even the most epic bughunt will tend make you lonely if accidentally used for conversation in polite society.
In one of my subroutines I changed the value of a passed in variable. In my code there was a point where I called that subroutine with the value '0' for the variable.
The Fortran compiler was pass-by-reference, so the compiler accommodated me by creating a reference to the constant 0 and passing it to my code. In my subroutine I changed the value of that passed in 'variable'. Since the compiler was using that "constant" elsewhere any conditional that looked for 0 would fail after that point since the value of 0 had changed.
My professor and I only found it after we printed out the machine code generated by the compiler.
How does that get through testing? "Passing a number to a subroutine can result in the value of the number being changed"?
void foo(Integer i) {
// Putz with reflection, change value stored in i to something else
}
main() {
foo(150); // Nothing special, you just created an autoboxed integer and then alter its value
foo(4); // Java pulls you an Integer from the autoboxing cache, and you do indeed accidentally alter the value of 4.
}
A subroutine receives values from the caller through
the parameter list; likewise, the subroutine returns
values by modifying the variables in the parameter
list. Subroutines are invoked in a FORTRAN program
as a statement, not an expression. The syntax used
is,
CALL name(actualParamList)
int increment(int x) {
x = x + 1;
return x;
}
int y = increment(2);
It wouldn't boot if you tightened the screws on the case.
Solution: Don't tighten the screws on the case.
Solution: Move the HDD such that tightening the screws doesn't bend the SATA cable out of making good contact!
The worse version is broken in-board signal paths.
Both ultimately result from mechanical distortion.