What was your longest debugging time?
We often hear how debugging can get really hard and can take hours and sometimes more than a day to find the problem.
Some year ago I asked a question here on forums if there is someone skilled with MS Media Foundation to help me debug my project, or if there is alternative audio library.
Sadly there was no one and I have given up, a week ago I decided to debug it no matter how long it would take.
Well you won't believe me it took me a whole week (cca. 10h per day) and I finally got my own audio library.
There is still stuff todo but I left a few fat comments for next time because I'm burned out.
That was surely the longest debugging time ever comparable to beginner's struggling but MS Media Foundation is such a pain the arse to get right.
Now that I shared my little story I'm wondering how much time did you spend to debug issues? I mean longest time ever?
Did it ever take more than a day and do yo prefer to give up?
Some year ago I asked a question here on forums if there is someone skilled with MS Media Foundation to help me debug my project, or if there is alternative audio library.
Sadly there was no one and I have given up, a week ago I decided to debug it no matter how long it would take.
Well you won't believe me it took me a whole week (cca. 10h per day) and I finally got my own audio library.
There is still stuff todo but I left a few fat comments for next time because I'm burned out.
That was surely the longest debugging time ever comparable to beginner's struggling but MS Media Foundation is such a pain the arse to get right.
Now that I shared my little story I'm wondering how much time did you spend to debug issues? I mean longest time ever?
Did it ever take more than a day and do yo prefer to give up?
Ive had plenty run more than a day, and usually for work so giving up isn't an option. Ive had a couple where just reproducing it took more than a day, before even entering the code itself.
The really worst issues occur in heavily multi-threaded code that can't be reproduced on-demand but do happen! I once had a situation where a particular program would 'randomly crash' after about 6 - 7 minutes (of about 1 usually 10 minute run) but would at other times work fine. Took us a few weeks and mega-bytes of debug file output to finally track the culprit down. Ahhh....
| The really worst issues occur in heavily multi-threaded code that can't be reproduced on-demand but do happen! |
I certainly believe you that because that's exactly what took me a whole week, MS MF is multithreaded COM API which I called from STA, and the issue I was running into is that I passed raw pointers from STA to an MTA which is not supported without marshaling the pointer and results in all sorts of weird bugs impossible to debug.
| Took us a few weeks and mega-bytes of debug file output to finally track the culprit down. Ahhh.... |
few weeks huh, that's real pain, but at least you were not alone.
I have found that when debugging gets difficult, I have not structured my program correctly. In every class I write, I try to include debugging facilities in that class.
Sometimes I have to step back and write a test framework for a class. I generally don't classify writing test frameworks part of debugging. That's part of design and coding.
If my test framework is not returning expected results, then I start debugging the framework and the target class.
This may sound simplistic, but in a project that has hundreds of classes, having a test framework for key classes saves a lot of debugging time.
Sometimes I have to step back and write a test framework for a class. I generally don't classify writing test frameworks part of debugging. That's part of design and coding.
If my test framework is not returning expected results, then I start debugging the framework and the target class.
This may sound simplistic, but in a project that has hundreds of classes, having a test framework for key classes saves a lot of debugging time.
| having a test framework for key classes saves a lot of debugging time. |
I definitely agree with that, I use MS test framework for unit testing and also write non unit test test projects ex. GUI.
In addition I make sure all warning are gone, however despite all this performed there were still bugs hanging around.
So in addition to testing and static analysis, I would recommend re-reading documentation for what ever API one is using, at least that's what helped me catch those bugs after a week.
IMO, testing and debugging should be taught as part of software engineering within a programming course/degree. We find that this isn't well taught - or not taught at all - in the university/college applicants we've come across. What 'skills' they have in this area have been mainly self taught/learned when they were developing programs for their courses. This is not new. I wasn't taught testing/debugging either as part of my degree course - although when we submitted our work we had to show that testing had been undertaken (with both expected and unexpected input). IMO these areas should have a more prominent place.
Reason why testing is not popular is the same as why writing code comments is not popular.
I takes time to write a test and also to update it for changes, and excuse seems to be that this time is better spent on writing code.
also if one is new to testing it also takes little time to learn testing framework and how to use it.
So I guess some people will just skip over for these reasons.
I don't know what to say about universities, I'm self taught coder but I can imagine in school you don't really learn anything unless you start working on a real project where fire burns.
I takes time to write a test and also to update it for changes, and excuse seems to be that this time is better spent on writing code.
also if one is new to testing it also takes little time to learn testing framework and how to use it.
So I guess some people will just skip over for these reasons.
I don't know what to say about universities, I'm self taught coder but I can imagine in school you don't really learn anything unless you start working on a real project where fire burns.
My longest debug time by far was an assembly assignment I had for my assembly class.
The assignment was to use openGL to display a Mandelbrot fractal. I coded it in a day or two, but it wouldnt work. It would only display a singular red pixel.
I debugged it for at least 3 days. I looked through every inch of code, I looked at registers, I stepped through the program countless times, never finding any issue. Every register, every variable, everything. They all held the correct values, the code executed as expected, but nothing would display.
The final day, I decided I would just try anything. I began with replacing all the "r" registers with variables - as I'd never used those registers before. Bam, the program worked. Like magic.
I still have no idea what the issue was to this day. I 100% did not use any reserved registers. The registers I removed, I confirmed many times, always held the right data.
The assignment was to use openGL to display a Mandelbrot fractal. I coded it in a day or two, but it wouldnt work. It would only display a singular red pixel.
I debugged it for at least 3 days. I looked through every inch of code, I looked at registers, I stepped through the program countless times, never finding any issue. Every register, every variable, everything. They all held the correct values, the code executed as expected, but nothing would display.
The final day, I decided I would just try anything. I began with replacing all the "r" registers with variables - as I'd never used those registers before. Bam, the program worked. Like magic.
I still have no idea what the issue was to this day. I 100% did not use any reserved registers. The registers I removed, I confirmed many times, always held the right data.
lol that is an interesting and slightly funny story :)
assembly debugging can surely be hard, especially 10+ years ago when debugging tools for assembly were in much worse shape than today.
In fact I don't know but troughout learning assembly I noticed today pretty much powerful tools for assembly exist, comparing to some old upon which I stubled upon, these don't really look like friendly.
assembly debugging can surely be hard, especially 10+ years ago when debugging tools for assembly were in much worse shape than today.
In fact I don't know but troughout learning assembly I noticed today pretty much powerful tools for assembly exist, comparing to some old upon which I stubled upon, these don't really look like friendly.
What assembly debugging? When I started assembly at university all we had was a printed core (yes, the memory was magnetic core!) dump! I remember writing a crude debugger. I think over the 1970's & 80's I wrote about 3 (not for Intel) on different systems.
Topic archived. No new replies allowed.