01.26.05
Technical Frustrations
Man, I’ve been stuck with problems that in the beginning look so straightforward, but as I “solve” them, turn out to be debugging monsters. Okay, let me explain:
1. I was supposed to fix the termination sequence in our program. Upon investigation, it turned out that it wasn’t even going through the termination sequence at all! So, all along, it had always had memory leaks AND orphaned threads. But then again, that application isn’t really critical anyway, since it’s just the equivalent app used mostly by our sales and tech personnel. Anyway, after I fixed that, I noticed that termination was actually intermittent – sometimes it works, sometimes it doesn’t. Then I had a memory leak log and an NTDLL.DLL Access Violation.
The thing is, when it does do that, the program actually terminates, so it gives the Access Violation when, after the program quits, the memory the program used is sent back to the heap. How do you debug that and where do you start looking for the error?
My debug procedures are as follows:
0. Search the net. A lot of people have actually come across the same problem. The solution? Nothing’s really clear. Everybody just says you’ve somehow corrupted the heap. Where exactly? Nobody has any suggestions on how to start looking for that. Some people have it easy, though. It’s just a matter of making sure you have your linker set up properly. Here is the info on that.
1. Disable functionality -> didn’t get too far with this. Too many errors came up, access and instantiations are buried way too deep, and everything is nested and knitted together.
2. Set up my symbols server so that the call stack makes sense. This helped me out, tricky to set it up though, because it didn’t work by just following the instructions.
3. Read Debugging Applications for .Net and Windows by Robbins, a good book, but I couldn’t enable my DCRT library due to some conflict. I was going to keep working on that but decided to just use Numega BoundsChecker and see if that does it.
4. Study and configure BoundsChecker and recompile to enable FinalCheck. So I was getting out of range pointer errors left and right deep in the microsoft libraries. Usually for CMAP, CLIST, etc.
I found a memory leak, fixed that, but didn’t fix the problem. Huh.
Anyway, we’ve decided to drop this since the error is only apparent in the Debug build. So, if the user can’t see it, it’s not a huge priority right now.
Right now, I’m fixing something that hasn’t worked for over a year, but nobody noticed until now. It feels like the Big Dig right now. Once they found the small leaks, they uncovered even bigger problems.
