Last friday’s rant about C++ static and dynamic analysis tools was picked up by Reddit and I have had quite a few helpful suggestions for other tools to try. Thanks!
Dr. Memory.
Microsoft’s Application Verifier.
CPPDepend
PVS Studio
Microsoft’s CRT Debug heap.
CLang - various options, especially using AddressSanitizer.
So far I’ve had a quick look at Dr. Memory, which seems to be pretty good. Free, easy to download and install and it’s faster than DevPartner and ‘just works’.
I tend to develop code with JITT (Just in time testing), this is like TDD when I’m doing it but it doesn’t always get done. What does get done, generally, is the “first test” for each class. This ensures that subsequent testing is possible as the code doesn’t have hidden dependencies and it gives me a test harness that’s ready to go when I find that I need it. More complex code end up being TDD, easier bits end up as JITT where the tests are only written when I’ve wasted time banging my head on the desk trying to debug problems the “old fashioned way”.
One of the things that came out of my conversations with clients last night was an interest in hosting .Net Core from native code.
Of course we already host the CLR and provide an easy way to write servers that do the heavy lifting in native code and call out to managed code for the business logic. We have several clients using this to host managed “plugins” inside a native host and it works very well.
I’m looking at adding support for the TLS Application-Layer Protocol Negotiation Extension to The Server Framework as a precursor to looking into HTTP 2.0 support. This TLS extension is supported by both SChannel and OpenSSL. It’s relatively new (only having been included in SChannel since June 2014 (!)) but there seems to be no documentation on MSDN for the structures and how to use them to add the appropriate entries to the TLS handshake and then to select and validate the protocol of your choice… Searching today with Google for something like “SEC_APPLICATION_PROTOCOL_NEGOTIATION_EXT” just gives just the usual selection of hits to people who think it’s clever to run the Windows header files through their document generators and then publish the results on the web…
I now have a real solution to the problem that I outlined on Saturday night and this solution, unlike the one developed during my “Macallan driven development” session on Saturday evening actually works.
The problem is that when using code to run build using VS2010 by running a project into devenv.com I get the following error message:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(214,5):
error MSB4175: The task factory "CodeTaskFactory" could not be loaded from the assembly
"C:\Windows\Microsoft.
Updated: 12 July 2015 - It seems that this is all incorrect… Upon running my tests again this morning I find that the x64 task runner also fails to run VS2010 correctly and so the environment differences are unlikely to be the cause…
So, having decided that my continuous integration system could be better, and having looked at JetBrains’ TeamCity and decided that it doesn’t quite fit I’m looking back at some code that I wrote back in 2008 when I last thought about this kind of thing…
I’ve just spent a day tracking down a bug in a pending release of The Server Framework. It was an interesting, and actually quite enjoyable, journey but one that I shouldn’t have had to make. The bug was due to a Windows API call being inserted between the previous API call and the call to GetLastError() to retrieve the error code on failure. The new API call overwrote the previous error value and this confused the error handling code for the previous API call.
Back in September I mentioned that I had found a problem with my usage of Slim reader/writer locks. I expected this to be something that I was doing wrong but it turned out that it was a kernel bug.
This morning Johan Torp tweeted that a hotfix for this issue is now available.
The note on the hotfix states: “Note These issues are not obvious and are difficult to debug. This update is intended for applicable systems to apply proactively in order to increase the reliability of these systems.
As I mentioned back in February I’ve been working on a custom video streaming solution for one of my clients. This has been a lot of fun. It was a nicely defined spec using industry standard protocols developed on a fixed price basis with lots of TDD, what’s not to like.
The system allows a controlling application to set up RTSP streams for broadcasting to multiple clients. The data for the stream is being transmitted live from one of thousands of smart (IoT) devices and the server buffers this and broadcasts it using RTSP to publish the RTP streams.
It looks like the Slim Reader/Writer issue that I wrote about back in September is a kernel bug after all.
Stefan Boberg has just tweeted to let me know that Microsoft has confirmed it’s a bug and that a hot fix is in testing.
