|
Re: Suspending Disbelief While Debugging
by JPaul (Hermit) on Dec 09, 2002 at 05:34 UTC
|
I find whenever I come across a bug in my own code that appears to defy logic or explaination, and its not immediately apparent what I've screwed up, then it inevitably falls into the category of a DUMB mistake.
Just one of those things, I suppose, but everytime I come across something like this... I just know its something really stupid, and I'm just not thinking well enough to spot it.
I'm kinda curious if the solution is the same for everyone else: Walk away.
I leave the programme alone for as long as possible (And, generally, depending on how nasty the code is, the longer I avoid the issue) and when I return, I return afresh. I run the programme. I get the error. I do a little debugging, and bam. There it is.
Hello, its Mr Wildly-Stupid-Muck-Up.
Anyone else share this?
JP,
-- Alexander Widdlemouse undid his bellybutton and his bum dropped off -- | [reply] |
|
|
Usually yes, the same for me too. I once caught a *very* stupid error where I was trying to assign the match of a regex in which my regex didn't have anything in parenthesis. Of course I was writing code quickly and probably thought that was the direction I was going, but after a few words that would make a sailor blush and a few hours away from it, I found it in a flash.
The only thing I've never been able to reconcile is when my windows machine gets wonky and code that has run perfectly before, suddenly doesn't run until I reboot. THOSE errors really get you. :)
There is no emoticon for what I'm feeling now.
| [reply] |
|
|
| [reply] |
|
|
Absolutely. Sometimes it happens when I'm debugging something and I get stuck, other times it happens during the design phase, when I'm trying to figure out data structures, etc. I find out that walking away is more efficient than sticking with it in many cases. Sometimes the answer comes to me on the ride home, or while I'm mountain biking, or mowing the lawn... then the trick is to remember the solution. I send myself emails, leave myself voice mails, or write the dreaded yellow sticky notes before that part of my brain is overwritten.
| [reply] |
|
|
I'm kinda curious if the solution is the same for everyone else: Walk away.
I leave the programme alone for as long as possible (And, generally, depending on how nasty the code is, the longer I avoid the issue) and when I return, I return afresh. I run the programme. I get the error. I do a little debugging, and bam. There it is.
Hello, its Mr Wildly-Stupid-Muck-Up.
I would assume that is an approach that appears quite often amongst those here. It makes sense-you get handed a problem, many times with someone breathing down your neck for a solution. Like a battlefield commander, you look at the problem opposing you, skirmish along its lines in attempts to find where best to hit it, form your battle plan, attack with all your forces... and your attack fails. You regroup your forces, and charge it again... and again... and again. You continue to attack along the same lines, until your attacks form muddy ruts in which you get stuck, attacking the same point over and over. Then you withdraw-the cost has been too high for little to no ground gained. You regroup, refresh, focus on other things for a bit, possibly even get new intelligence about your foe and its actions. When you return to that problem, you now come to it with a fresh view, and seeing it anew, you spot a better target point, or think of a better attack plan, and execute it, winning the day.
(Yes, do it all the time.)
| [reply] |
Re: Suspending Disbelief While Debugging
by gjb (Vicar) on Dec 09, 2002 at 08:27 UTC
|
I find that writing tests before writing the code to be tested helps to catch a lot of dumb mistakes. Also, writing a test for the obvious seems like a waste of time, but it may help preserve sanity in case of an acute attack of stupidity.
It also helps to consider refactoring the code (there's always something smelly) since it forces one to rethink the code. It ties in with the Extreme Programming paradigma which represents some nice ideas.
Just my 2 cents, -gjb-
| [reply] |
Re: Suspending Disbelief While Debugging
by shotgunefx (Parson) on Dec 09, 2002 at 10:24 UTC
|
Whenver I encounter an error like that, I assume it's me and keep hacking away. Only after exhausting the likely possibilities, do I move on to the improbables, the bugs in the code I'm coding in.
I've been bit more than a few times but implementation defects. My first (and worst) experience was a 3d renderer I was working on. I was only programming a few years at the time.
It used "psuedo-raycasting" to draw textured map roads (a racing game). Thousands of lines of C && Assembler (386, everthing was unrolled). I kept getting garbage at the horizon. It would just randomly change heights. I poured over and over the code, making sure it wasn't a "1 off" error. I just couldn't solve it. After a month of beating my head of the wall, I switched to other projects, periodically coming back to it and repeating the cycle.
Then a few months later I came bace and fixed it in 10 minutes. The solution? I entered a blank line in the C source (to make an expression easier to grok). That's it. No other changes. I still don't understand exactly how it was breaking it but the source file's layout hit the compiler just so that it would cause it to compile slightly different even though the text (minus the newline) was exactly the same. After that, nothing is beyond suspicion. :)
-Lee
"To be civilized is to deny one's nature." | [reply] |
Re: Suspending Disbelief While Debugging
by adrianh (Chancellor) on Dec 09, 2002 at 16:41 UTC
|
Many years ago a friend of mine was working on a mocked up ATM type system that ran over a serial line. This included some self-tests to make sure that the line was up and running okay.
When writing the self-test code he kept hitting this problem where the working test line was being diagnosed as failing. Spent most of a day going over the assembler code in question. We got to the stage where we were questioning the serial driver hardware in the machines and were looking around for spares.
Very late that day we finally thought to check that the test lead was actually working... You should have heard the howls when we realised we'd wasted most of a day on some dodgy wiring.
I still look back at that and wonder at our complete inability to accept that a few hundred bytes of obvious code was working properly. We knew that it must be a bug :-)
It proved a salutary lesson for me. Always try and disable your assumptions when debugging and look at what is actually happening.
| [reply] |
|
|
| [reply] |
Re: Suspending Disbelief While Debugging
by talexb (Chancellor) on Dec 09, 2002 at 16:44 UTC
|
I guess the best story I have in that genre comes from my first work term in Fall 1977, while debugging a multiplication routine in assembler.
After running a few tests, it became clear than a Branch If Greater Than worked fine if the difference between the two operands was large, and it continued to work down to a difference of two, but a difference of one wouldn't take the correct branch. After checking and rechecking my work, I threw myself on the mercy of the harware engineer, who got out his scope and hooked it up to the backplace, then confirmed that there was 'some noise' there. He removed and reattached some wires, checked his work, and after that my code worked fine.
--t. alex
but my friends call me T.
Update: Deleted a redundant 'after that' at the end.
| [reply] |
Re: Suspending Disbelief While Debugging
by RMGir (Prior) on Dec 09, 2002 at 16:51 UTC
|
Neither the google cache nor the original link work for me, but I think this will work.
This reminds me of the time I was debugging someone else's C++ code, which returned a const char * from a conversion operator.
The value was "magically" changing 2 calls later.
It turned out the pointer being returned was to a buffer on the stack with enough other locals in front of it that the first call wasn't overwriting it...
--
Mike | [reply] |
Re: Suspending Disbelief While Debugging
by dingus (Friar) on Dec 09, 2002 at 18:38 UTC
|
2 rules for troubleshooting
- 90% of problems are caused at the physical layer
- The first question to ask your user is "What (apart from nothing) has changed since it worked?"
Then you get the other bugs caused by stupidity - such as the pure genius one I wrote on Thursday and found (late) on Friday where I broke something out into a subroutine and reused $_ without a local. Do not do this. Did you know that doing push @{$$_{$var}} when $_ isn't a reference anymore can cause your perl program to crash abruptly without even reporting anything on STDERR?
Dingus
Enter any 47-digit prime number to continue. | [reply] |
Re: Suspending Disbelief While Debugging (some more)
by dws (Chancellor) on Dec 10, 2002 at 18:08 UTC
|
| [reply] |