|
An intermittant problem that shows up only when you're writing code at home, not at work. Crashes hard at home with all kinds of OutOfMemory failures, but the machine isn't out of memory or resources at all. Not even close.
After 5 hours of fruitless debugging, the painful part is where you facepalm yourself hard because you just realized that in a Parallel.ForEach your using around an I/O bound problem, you forgot to cap the number of threads it can create! The process bombed out at about 600 threads.
Whoops!
|
|
|
|
|
Dave Kreskowiak wrote: Whoops! Every great developer has said that before.
It's the terrible developers that never say that either because they don't know when they screw up or they won't admit it.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Whoops
In code we trust !
|
|
|
|
|
We have an application that automates the running of other applications we have that take data feeds from clients and process them. Automation uses a command line to kick of the different processing programs.
All of the sudden the automation starts logging an error even though the processing completes successfully. I finally track down the location of the line that is recording the log message. The code in automation scans the log file of the processing program for the string "error" and reports if it finds it. I look through the log files of the processing programs and everything looks normal, no errors being reported. After several more reports of this problem I am looking at the log file again and I finally find the cause of the problem. The file services people who manage the automation process wanted more detailed logging, to include recording the command line parameters being used for each different run of the processing application.
One of those command line parameters is used to turn on and off message/error logging. The message sent to the log file for the logging switch said,
"Command Line Parameter to log errors"
WHOOPS!
Yes, I added that code.
|
|
|
|
|
|
|
Whatever is the root cause of this it sounds like it will be fascinating.
|
|
|
|
|
The gravity pull is stronger on the 2nd floor. The bits are slowing down through the ethernet.
http://dilbert.com/strips/comic/1996-05-02/[^]
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Maybe it's a very tall building, and he's experiencing gravitational time dilation.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
"When you don't know what you're doing it's best to do it quickly"- SoMad
|
|
|
|
|
Epic.
We should be building great things that don't exist-Lary Page
|
|
|
|
|
Bad cabling most certainly. Any switches plugged into themselves?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Bad cabling most certainly
Nope. They need amplifier on terrace...
"When you don't know what you're doing it's best to do it quickly"- SoMad
|
|
|
|
|
Wouldn't that only amplify the problem?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Easy to find out: offices of high ranking people are farther upstairs, they get computers with highest specs and the most modern network etc. Let me guess: developers are in the 2nd floor.
|
|
|
|
|
Bernhard Hiller wrote: developers are in the 2nd floor.
They're probably in the basement.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Bah, off-shored.
Bernhard Hiller wrote:
developers are in the 2nd floor world
FTFY
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I am assuming that the server is deployed on the 4th floor.
What is happening is that the bytes are being nibbled away by each floor so that by the time they reach the 2nd floor only nibbles are left - hence causing problems on the second floor.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Easy! Just do a text search in the code for something like
if (floor == 2)
{ }
and you'll locate the problem in a second! 
|
|
|
|
|
Five or six times longer...
[Browsable(false),
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public IEnumerable<int> SelectedIndexes
{
get { return dgvData.SelectedRows.Cast<DataGridViewRow>().Select(r => _DataSource.Rows.IndexOf(((DataRowView)r.DataBoundItem).Row)); }
set { ... }
}
I almost wish I'd written it longhand instead of using Linq methods...
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
|
Fantastic! I thought I was the only one who wrote comments like that. I feel so much relief! Thanks Griff.
|
|
|
|
|
I just know that in a years time I'm going to look at that line of code and go "What? Why?"
Perhaps I can head myself off at the pass!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Sometimes it is easy to understand by looking at the code rather than the comment. There are such programmers.
|
|
|
|
|
I write comments like that too, especially if I have to do something that isn't obvious as to WHY I'm doing it. (Usually because the client is asking for something that's just the opposite of what they wanted six months ago.)
It also lets other people know to think twice before changing that code willy-nilly.
|
|
|
|