• Advertisement
Sign in to follow this  

Memory Corruption - using third party tools to troubleshoot.

This topic is 2349 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I'm a C++ developer and I keep running into memory corruption issues. To this day I've always been able to fix those errors, but it takes a lot of time which I'd rather spend coding.

I thought MSVC had some sort of memory corruption detection (memory guards?) but they never trigger or show me any useful information. If I'm lucky I sometimes get shown *what* was corrupted, but not when. I even implemented my own memory guards and increased their size to see if I could spot any corruption, but I couldn't. They were perfect.

Mostly the stack trace is corrupted itself - not very useful.

I thought I'd try Purify, Valgrind or Insure++. Are these worth it, in your opinion? Are there any alternatives that won't empty my wallet?

Thanks!

Share this post


Link to post
Share on other sites
Advertisement
I just tried the Purify trial and it does seem magic. It tells me I got a dozen issues but I can't check any without buying the full version which is a month's salary for me.

Thanks SiCrane! I've tried the Application Verifier before but I can't remember if it helped. I'll try again.

Share this post


Link to post
Share on other sites
I don't think they will address the problem you are having. It is possible to make your memory protected and then writes will cause an error. However I am not sure how to do that in VC++.

Share this post


Link to post
Share on other sites
That's one of the options in Application Verifier. It adds a guard page after the end of memory allocations so that you get a access violation upon buffer overrun.

Share this post


Link to post
Share on other sites

That's one of the options in Application Verifier. It adds a guard page after the end of memory allocations so that you get a access violation upon buffer overrun.


When does it tell me I've overstepped my bounds, upon new/free or upon the actual operation? That's my major gripe with MSVC's debugger.

Share this post


Link to post
Share on other sites
When you overrun the memory. It's a normal access violation just like if you wrote to a null pointer.

Share this post


Link to post
Share on other sites
Application Verifier shows 0 errors and 0 warnings for me, and the log is empty. Even when I deliberatly make buffer overruns. It detects program startup and the correct checkboxes are checked.

Oh well.

Share this post


Link to post
Share on other sites
If you're scribbling over stack memory, there's probably not a lot a tool like application verifier can do as the stack area has to stay highly mutable (though I've never used it -- interested to hear if I'm wrong).

A low-tech solution would be to use something akin to boost::array<> rather than raw arrays that will catch overruns via assertions in operator[], etc.

EDIT: Oh, and /RTCs is worth a punt if you haven't tried it already.

Share this post


Link to post
Share on other sites

If you're scribbling over stack memory, there's probably not a lot a tool like application verifier can do as the stack area has to stay highly mutable (though I've never used it -- interested to hear if I'm wrong).

A low-tech solution would be to use something akin to boost::array<> rather than raw arrays that will catch overruns via assertions in operator[], etc.

EDIT: Oh, and /RTCs is worth a punt if you haven't tried it already.


Yeah, I'm using safe arrays (and the RTCs switch) but they can't catch when you use a raw pointer and go out of bounds on that. I guess I'll have to take a look at Purify again..

Thanks everyone!

Share this post


Link to post
Share on other sites
Do you need to use raw pointers then, if safety is a critical concern?

If you use checked alternatives, you can isolate your raw pointer manipulation to the few places that profiling might indicate are necessary.

Share this post


Link to post
Share on other sites
Is your code cross platform? You could also try mudflap with g++. Unfortunately, it doesn't work with MinGW as far as I can tell.

Evidently you need to strt making more liberal use of tests and assertions, but the other thing you can try is to revert to former revisions to find out in which changeset/commit the problematic behaviour was introduced.

If you're not using version control yet, here's your motivation.

Share this post


Link to post
Share on other sites
Also try HeapAgent, I remember using them a few times and it worked out better than the others..

http://www.microquill.com/heapagent/index.html

I've also used BoundsChecker it works but is very slow, that's last resort, if the other 2 don't catch it..

Also i remember also trying Memory Validator, it was advertised on CodeProject..

http://www.codeproject.com/KB/showcase/memoryvalidator.aspx

They both have free trials you can use to test your code against..

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement