DevPartner , Purify, alternatives ?
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
Send your code to me, I will test it, and only charge you 1/2 weeks salary. :)
Best wishes, Hans
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
-
Nemanja Trifunovic wrote:
Have you tried using debug CRT[^]?
are you asking if have i run the app in debug mode ? :confused:
-
Nemanja Trifunovic wrote:
Have you tried using debug CRT[^]?
are you asking if have i run the app in debug mode ? :confused:
:laugh:
Watched code never compiles.
-
Nemanja Trifunovic wrote:
Have you tried using debug CRT[^]?
are you asking if have i run the app in debug mode ? :confused:
I mean have you tried using the goodies from crtdbg.h? Also, you can set some memory checks from GFLAGS.
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
I've never found a satisfactory replacement to DevPartner. (I evaluated several, including AQTime, which was utter garbage.)
-
I had to resort to using that, when I failed to get BoundsChecker work with reasonable performance for my application. Detecting memory leaks is painful. You have to run the application exactly the same each way to get the allocation number's consistent. Also there is no good way to detect memory overwrites. Eventually, I think code review and intense testing is the only way to get these things sorted out.
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
I sometimes use Visual Leak Detector - Enhanced Memory Leak Detection for Visual C++[^]. Sometimes reports tons of false positive, but other times works well.
Watched code never compiles.
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
I used briefly glowcode in the past http://www.glowcode.com/[^] it was cheap, did the job, but the UI was crap
Stephane
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
Years ago we used a tool called Mutek BugTrapper which would catch memory overwrites, etc. but that was probably 10+ years ago. You might have to do this the hard way - build your libs with debug info, hang onto the PDB files and ensure any crashed generate a minidump file which you can then debug with either WinDbg or Visual Studio itself. The debug CRT functions would allow you to selectively surround suspicious code with guard checks, etc. It would be painful. I've recently switched to using the dynamically linked CRT for my latest application so I could take advantage of crashrpt[^], which can email a crash dump back home. It was a days work switching from the static CRT, and involved plenty of Google searches and a couple of posts on Stack Overflow (I link with the latest SP1 versions of the CRT by defining _BIND_TO_CURRENT_CRT_VERSION). I ship the CRT DLLs too - you just need to stick them in the application folder and make sure you include the manifest. The biggest ball-ache was with some Boost libs that were pulling in a different version of the CRT, so I had to flex my bjam muscles and rebuild with _BIND_TO_CURRENT_CRT_VERSION. I found a cool tool (XN Resource Editor or something) to check the manifests of all my DLLs and EXEs to ensure they all used the same CRT version.
-
Years ago we used a tool called Mutek BugTrapper which would catch memory overwrites, etc. but that was probably 10+ years ago. You might have to do this the hard way - build your libs with debug info, hang onto the PDB files and ensure any crashed generate a minidump file which you can then debug with either WinDbg or Visual Studio itself. The debug CRT functions would allow you to selectively surround suspicious code with guard checks, etc. It would be painful. I've recently switched to using the dynamically linked CRT for my latest application so I could take advantage of crashrpt[^], which can email a crash dump back home. It was a days work switching from the static CRT, and involved plenty of Google searches and a couple of posts on Stack Overflow (I link with the latest SP1 versions of the CRT by defining _BIND_TO_CURRENT_CRT_VERSION). I ship the CRT DLLs too - you just need to stick them in the application folder and make sure you include the manifest. The biggest ball-ache was with some Boost libs that were pulling in a different version of the CRT, so I had to flex my bjam muscles and rebuild with _BIND_TO_CURRENT_CRT_VERSION. I found a cool tool (XN Resource Editor or something) to check the manifests of all my DLLs and EXEs to ensure they all used the same CRT version.
yeah. that doesn't sound like any fun. :) the biggest problem i'm facing is that i can't reproduce the problem. i have a user who can duplicate it, no problem, and he's apparently happy to run any tests i give him. but so far i haven't even been able conclusively pinpoint the point of failure. i have status logging at the start of nearly every function in the app, and he sends me the log files after the crashes. but, when he changes settings in section A, the app crashes in section K. blah. i suspect a memory overrun or stray pointer, but i can't figure out where it might be...
-
yeah. that doesn't sound like any fun. :) the biggest problem i'm facing is that i can't reproduce the problem. i have a user who can duplicate it, no problem, and he's apparently happy to run any tests i give him. but so far i haven't even been able conclusively pinpoint the point of failure. i have status logging at the start of nearly every function in the app, and he sends me the log files after the crashes. but, when he changes settings in section A, the app crashes in section K. blah. i suspect a memory overrun or stray pointer, but i can't figure out where it might be...
Have you tried using mini dumps?
-
Have you tried using mini dumps?
no, because i don't get any. the app doesn't actually crash, it just throws itself into a very high-level catch (...). :-O (and it doesn't even do that, when i try to duplicate the problem). i suppose i could get rid of that catch(...) ... see what happens after that.
-
i used to use BoundsChecker (now "DevParter") and found it to be very useful for catching pointer/memory overrun errors. but, the upgrades grew too expensive and the version(s) i have won't work with any of the modern Visual Studios (or Windows). so, i've been looking for something to replace it. the latest DevPartner is ~$1500, and so is Purify. that's way more than either of them worth, to me. i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation. is there anything else out there that's any good at catching memory/ptr problems, which doesn't cost a week's salary ?
Chris Losinger wrote:
i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation.
You are mistaken about Memory Validator. Memory Validator has been capable of detecting memory leaks in statically linked code for some time. I think I've found the text on the Memory Validator feature list that gave the wrong impression. That will be removed today.
Stephen Kellett -- Memory Validator. Faster Leak Detection, Better Analysis. http://www.softwareverify.com http://www.objmedia.demon.co.uk/rsi.html
-
yeah. that doesn't sound like any fun. :) the biggest problem i'm facing is that i can't reproduce the problem. i have a user who can duplicate it, no problem, and he's apparently happy to run any tests i give him. but so far i haven't even been able conclusively pinpoint the point of failure. i have status logging at the start of nearly every function in the app, and he sends me the log files after the crashes. but, when he changes settings in section A, the app crashes in section K. blah. i suspect a memory overrun or stray pointer, but i can't figure out where it might be...
Take a read of this article I wrote on strange pointer values. Ignore the bit on the various values if you are not interested in the strange pointer values and work your way down to "What can you do to prevent the cause of these problems?" where you will find a list of things to check that can cause spurious failures. The link to that article comes from the blog, which contains other hints and tips.
Stephen Kellett -- Memory Validator. Faster Leak Detection, Better Analysis. http://www.softwareverify.com http://www.objmedia.demon.co.uk/rsi.html
-
Chris Losinger wrote:
i looked at Software Verification but found it unusable because it requires you to build with the dynamically-linked CRT (which none of my stuff does) before it can do any memory validation.
You are mistaken about Memory Validator. Memory Validator has been capable of detecting memory leaks in statically linked code for some time. I think I've found the text on the Memory Validator feature list that gave the wrong impression. That will be removed today.
Stephen Kellett -- Memory Validator. Faster Leak Detection, Better Analysis. http://www.softwareverify.com http://www.objmedia.demon.co.uk/rsi.html
i needed more than just leak detection, which you're right it did do. i also needed stray/orphaned pointer detection. sorry if that was unclear.