A Different Kind of Bug Database
When it comes to debugging, programmers become a bit like doctors. You look at the symptoms. You run some tests. You poke. You prod. You get your code to turn and cough. With any luck, you come up with the correct diagnosis and address the problem.
Of course, we aren’t always right or we forget how we fixed that one bug last year. As a result, we spend much more time on a bug than is necessary as we have to “re-learn” it.
Now, I’ve heard that doctors have access to databases where they can look up cases and cross-reference symptoms and diseases. Why not something similar for programmers? It’s a bug database, but not the type of database you normally use. It would be a meta-bug database of sorts. It would list bug “symptoms” from which you can find explanations of the problem, lines of investigation and possible solutions. It’s like a bug database after you’ve done a post-mortem on a problem.
Here’s a simple example:
Symptoms:
“selector not recognized”Explanation:
An object is being sent a message that it does not implement.Further Steps/Solutions:
- You may have misassigned it. Make sure the object being called is of the class you think it is.
- You may have freed the object and its memory location subsequently has been populated with something else. Check your memory management.
- You may be accessing an uninitialized variable. Compile with -Wuninitialized.
Now, the last one I listed there was not something I would think of immediately, which is the point of this. In addition, I’m sure there are also other cases I didn’t list.
The database would draw upon the collective experience of programmers and would help to guide and expose new avenues of investigation. So, the idea is to start a colloborative, wiki-like bug reference database. I don’t know the how, who and where but I thought I’d put the idea out there to see if it gets any traction. Maybe it already exists in which case let us know about it.
Category: Debugging, Programming 9 comments »
March 22nd, 2007 at 11:37 am
Sounds like a job for a wiki. How about starting it under the venerable #macsb wiki: http://macsb.ironcoder.org/ ?
March 22nd, 2007 at 11:45 am
I’m all for it. Post the link here if you set it up.
March 22nd, 2007 at 12:11 pm
Would it make sense just to put this into the cocodev.com wiki tht already exists, so there is a cross reference to what’s there now? There actually is a lot of diagnostic information there already….
March 22nd, 2007 at 12:20 pm
Dan,
Probably not a bad idea. Things do tend to get burried in cocoadev though. It is a great resource I just wish it did a better job presenting and organising the data.
March 22nd, 2007 at 12:47 pm
The information is out there. Like Jonathan said, it’s an issue of presentation and organization. As it is, we have the resource in the form of the internet and a search engine.
My thought was that it would be more like a reference, not a discussion. The entries would be concise and to the point and well-structured. It would be as if someone condensed the Cocoadev discussions on a topic into a Wikipedia article. I don’t care who said what when, just what the final conclusions are. Maybe a Cocoadev subsection?
March 22nd, 2007 at 5:25 pm
It’s a wiki, it isn’t cant be properly presented or organized.
That’s the problem with not having a central body responsible for that.
March 22nd, 2007 at 5:34 pm
Excellent idea! I know Google works pretty good for finding answers by just googling the error message, but not rarely you just get unanswered forum posts or stupidly designed message list archives.
However — NOT on a wiki! Please oh PLEASE! Can’t be pretty-presented as Scott says, the data can’t be consolidated or bitshuffled or handled in any way except as strings. Euch.
Could probably be thrown together pretty fast in rails.
March 23rd, 2007 at 4:59 am
The idea is a good. The most important thing is a place for the crash log, stack trace, error or warning. As we would all describe a bug differently but not the computer, it would make the database very useful if you could limit the search just to that field.
If it’s built on Cocoadev it should be like the Cocoadev users page where any new bug page has a tag that would make it show up alphabetised on an index page to be searched by title and description.
Maybe I am asking for too much and not doing anything about it. I’ll go away now and think.
March 23rd, 2007 at 3:43 pm
I think the key is that the search is primarily on the symptoms. It is meant to solve problems not be something that is browsed. Keywords/tags/categories of some sort are also needed. Maybe at some point, have a “20 questions” style interface where successive questions are asked until the problem is narrowed down. A virtual bug doctor, if you will.
I’m wondering if using a modified version of Mantis or Trac would work to start off with. Otherwise, Joachim, are you volunteering do to a rails version 🙂 ?