The deadlock detection tool that I was working on last week is coming on nicely. I managed to locate two potential deadlocks that had never caused any problems in code that is running live on a client’s site. Once I had a report from my tool it was relatively easy to fix the problems. Both of these were real bugs that just hadn’t bitten yet.
Today I added some rudimentary lock contention monitoring to the tool and the results seem to be quite useful…
This G’n’R/Beatles mashup works surprisingly well, and brought a smile to my face earlier in the week - via Code Circle.
And whilst we’re on the subject of music, Filip has started uploading some of his techno mixes…
As I mentioned in an earlier posting I’ve been working on a tool this week. I’m too lazy to do a job manually and so I decided to write a tool to help me do it…
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
The tool is designed to help me track down deadlocks in code. I decided I needed this tool because I wrote a piece about debugging deadlocks in Visual C++ and realised that using trial and error to locate deadlocks in some client code simply wasn’t good enough.
One of the things that I’ve always been a bit unsure of is the claim by dynamic languages crowd that static typing buys us nothing as the unit tests solve the same problem. It’s a nice idea but I’m a bit scared that the unit tests required would have to be quite a bit better than my unit tests usually are… Anyway, it’s nice to see Brian Marick posting about how his usual retort of ’the unit tests will catch the bugs that the static type checker would’ was wrong…
There’s an interesting post over on the Joel On Software forums about RAII in C++. The original poster’s problem is clearly stated in the first line of their question:
When the constructor for CTheClass runs, I want to acquire 3 resources. These 3 resources will be freed in the destructor (that’s RAII, right?)
Wrong.
The question goes on to point out that if one of the constructors of one of the resources throws and exception then, because the CTheClass constructor hasn’t completed the CTheClass destructor doesn’t run and the resources that were successfully allocated aren’t released.
Ahsan Askari asked the following in a comment to one of yesterday’s posts:
Just like to know whether you use external libraries specially ‘BOOST’ in your commercial projects and related pros-n-cons ?
*
*Also i like to know your initial strategy of Software development. I mean you’ve written a lot about your coding and tsting techniques but i like to know how you start the project, whether you believe in UML and how you carry out analysis.
I’m still reading someone else’s code and it just struck me that a lot of ‘strange’ coding practices become unnecessary if you factor your code ‘correctly’. Note that both ‘strange’ and ‘correctly’ live in the Len::Personal::ViewOfTheWorld namespace…
Take this, for example:
// show line number info, NT5.0-method (SymGetLineFromAddr64()) if (this->m_sw->pSGLFA != NULL ) { // yes, we have SymGetLineFromAddr64() if (this->m_sw->pSGLFA(this->m_hProcess, s.AddrPC.Offset, &(csEntry.offsetFromLine), &Line) != FALSE) { csEntry.lineNumber = Line.LineNumber; strcpy_s(csEntry.
I’m looking at some code to help me understand how to use the dbghelp.dll Windows stack walking and symbol discovery stuff and the code I’ve found on the net uses a programming style that I’ve seen a few times before and have never understood the reason for.
if (this->m_sw->pSGSFA(this->m_hProcess, s.AddrPC.Offset, &(csEntry.offsetFromSmybol), pSym) != FALSE) { strcpy_s(csEntry.name, pSym->Name); // UnDecorateSymbolName() this->m_sw->pUDSN( pSym->Name, csEntry.undName, STACKWALK_MAX_NAMELEN, UNDNAME_NAME_ONLY ); this->m_sw->pUDSN( pSym->Name, csEntry.undFullName, STACKWALK_MAX_NAMELEN, UNDNAME_COMPLETE ); } else { this->OnDbgHelpErr("SymGetSymFromAddr64", GetLastError(), s.
*Piracy is not an enemy until you are famous.
Until that point, obscurity is your enemy.
I think independent creators should spend all of their attention fighting obscurity until they are famous, and only then should start to worry about piracy.*
Derek Silvers, via microISV
Just finished reading Undocumented Windows 2000 Secrets: A Programmer’s Cookbook by Sven B. Schreiber. Well, I say reading, it was really just a first pass through the book. The text and code spends more time in kernel mode than user mode; there’s a lot of information in there and it’s all relatively new to me so it’s the kind of book that needs a fair bit of work.
Sven starts by explaining how to set up a system that you can use for kenel mode development, you don’t want to use your main box as it will be blue screening a lot of the time.
