DevPartner Studio 9.0

| 8 Comments

I've just updated my installation of DevPartner Studio. I mainly use the C++ error detection part of this suite, that's the bit that used to be called BoundsChecker. Anyway, version 9.0 is the first version to support VS2008 and x64 so I was quite excited to be able to run the tool on my dev box rather than on my old x86 dev box.

Unfortunately my first impressions aren't good. Here's some of the output from the build window whilst the build is being built for "Error detection". Note the garbled output from some of the "Instrumenting" lines... This looks like a classic case of failing to correctly terminate a string, or a case of reading more memory than you're supposed to read. Either problem is something that the tool itself should be able to spot if it were ever run on its own code...


3>Generating Code...
3>Instrumenting .\CheckRegistry.cpp
3>Instrumenting .\CompareAndLog.cppGetmonths
4>MockTickCount64Provider.cpp
1>TimeChangeNotificationMonitor.cpp
3>Instrumenting .\StackWalker.cpp¦
3>Instrumenting .\TestException.cppö6L
3>Instrumenting .\TestLog.cpp6
4>MockThreadPoolWorkerThreadFactory.cpp
1>ThreadPoolCollection.cpp
3>Instrumenting .\TestMonitor.cpp
4>MockThreadPoolMonitor.cpp
1>ThreadPool.cpp
3>Instrumenting .\CallStackCreator.cppÇ
4>MockLocalTimeProvider.cpp
1>ThreadLocalStorage.cpp
4>MockJobMonitor.cpp
1>ThreadedCallbackTimerQueue.cpp
4>MockDirectoryChangeMonitorCallback.cpp
1>ThreadAffinity.cpp
4>MockCollectableThreadPool.cpp
1>Thread.cpp
4>Generating Code...
4>Instrumenting .\MockCollectableThreadPool.cpp
1>TempDirectory.cpp
4>Instrumenting .\MockDirectoryChangeMonitorCallback.cpp
4>Instrumenting .\MockJobMonitor.cppÇ■
1>SystemTime.cpp
4>Instrumenting .\MockLocalTimeProvider.cpp£Ã
4>Instrumenting .\MockThreadPoolMonitor.cpp56
1>StringConverter.cpp
4>Instrumenting .\MockThreadPoolWorkerThreadFactory.cppeck_D_110456
1>SmartStartupInfo.cpp
4>Instrumenting .\MockTickCount64Provider.cppTR
4>Instrumenting .\MockTickCountProvider.cpplib

8 Comments

I've never had a good time with Boundschecker. Admittedly the last time I ran it was with version 6 (or was it 5.5?).

What put me off was
a) awfully slow code
b) new with no delete wouldn't cause an error but
c) it found allocation errors every time I used vector
d) it crashed a lot

G.

I know the feeling. I find that it's most useful for checking my library code when running my test harnesses. Running on real applications tends to slow them to a crawl... I found v8.2 quite useful, but you do need to spend a while supressing lots of benign warnings.

So far my experiences with 9.0 on x64 are not at all good. I've yet to get any of my non trivial test harnesses to run without problems which all look to be caused by BoundsChecker... Grrr. I'll try it on an x86 system next week, but right now I'm wondering if they bothered testing it at all...

Likewise, I was looking forward to the upgrade to get the VS2008 support, but I've been seriously dissapointed. When I run my app instrumented for error detection it just crashes.

Are you running VS2008 on x86? If it's crashing on that as well then I'll not bother installing it on my old dev box to try it there...

I would imagine that the crashes would still be present on VS2005 as it's probably only the integration that changes...

:(

Sadly, between DevPartner and Purify, only DevPartner can instrument and correctly run xlls hosted by Excel. So we're limited to purify, and it seems to me that purify is just in 'maintenance mode' these days.

Well, it seems that the instrumentation issue is a 'known bug'. I reported it via Compuware's Frontline and they sent me a link to a zip to download a patch. Unfortunately there seems to be no list of currently known bugs which makes the product somewhat like a frustrating adventure game that I'm not especially interested in playing....

We saw the same thing with DevPartner 9.0 It crashes almost immediately in both performance and memory profiling. Sadly we kept waiting and the product kept delaying. We would up switching to AQTime which worked flawlessly for our needs.

Well, they eventually fixed all the issues I had with it and I ran it on some more code; it barfed with some different issues. I'm still waiting for that one to be fixed... :(

Leave a comment