Bugs and more bugs

By Marcus Wilson 07/11/2011 2


I’ve spent a frustrating day trying to drive out the bugs in one of my computer programmes. It’s a piece of computer code that is implementing equations describing how neurons talk to each other. I knew there was a bug because my modelled neurons were clearly not firing at the rate they should be. It wasn’t an easy bug to find – and on the way I ran across another one – but I got there in the end (about four hours work). Having found and fixed that bug, it’s clear that there is at least one more in there, and I’m now trying to track that one down.  Although my neurons now fire at the rate I expect, my neurons don’t communicate with each other properly. This one’s proving really awkward to find. Haven’t got there yet.

Finding bugs really is a slow process sometimes. It needs to be done very systematically. if you know what result you should get out for a given set of conditions, you can test every piece of the computer programme to see if it is doing what it should. Slowly you can home in on what the problem is.

Often, when you find them, bugs can be really small things. Like a ‘+’ sign instead of a ‘*’ sign, or a variable name spelt incorrectly. At least the days of FORTRAN77 are over – when variable names could have a maximum of six characters. That led to many variables having very similar names and opening up a lot of potential avenues for bugs to creep in.

My most difficult bug so far was a FORTRAN90 bug in a HUGE programme (thousands of lines of code) that I was working on in my previous job.  (N.B. I didn’t write the programme – I was tasked with making some modifications to it.) It was clear that one piece of it wasn’t doing what it should, but finding the bug took me a week. In the end I had to work my way through the code line by line, checking calculations with a calculator, until I got it. And when I found it, it was  unbelievably trivial. Just a typing mistake – a single character that shouldn’t have been there, but it altered what the line of code was telling the computer to do, and resulted in a big difference in the result of the end calculation.

A lot of theoretical physics research these days is just what I’ve described. Forget analyzing strange equations describing black holes or neutrinos or quasi-fluids and predicting new phenomena – All too often what you are really doing is looking at computer code that ain’t working and pulling your hair out.

 


2 Responses to “Bugs and more bugs”

  • The most stubborn single-character error I can recall was in a piece of COBOL, where the full-stop terminating an IF statement was the 81st character in the line. COBOL, being based on 80-column punched cards, simply ignored it, which totally screwed a very complex piece of logic.

    Sometimes the most error-prone parts of code were those that effectively said “on this logical branch, no action is required.”

    As a result of this and similar experiences, I wrote an article on the many forms of this statement; headlined “don’t just sit there, do nothing.”

    Much reader correspondence followed, as a result of which I wrote a sequel “Don’t just do nothing; do something zero times”. That’s often the neatest and safest solution. Or it was in the COBOL days, anyway.

    • I’ve never programmed in COBOL but that kind of a bug has a certain ring to it… My mother used to use COBOL punch cards as a young computer programmer in the 60’s – she tells me that they used to have to programme ‘stops’ in activities for five minutes every hour to let the valves cool down.

      Anyway, the good news is that I’ve found that third bug this morning so a good start to the day :-)

Site Meter