Jump to content
  • Advertisement
Sign in to follow this  
Burnt_Fyr

_CrtSetBreakAlloc() not breaking

This topic is 812 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

I'm trying to resolve a memory leak but have not been able to get the debugger to break on allocation of the leaked memory.

 

_CrtSetBreakAlloc() sets the proper value(I have verified it's not -1), but the program never breaks, or indeed any allocation. Is there something I'm missing?

 

The problem is deterministic as each time it is the same Alloc id(147), with the same size (8 bytes, which leads me to wonder, what could i be allocating that is 8 bytes? a wchar_t maybe?). Unfortunately as each time the program is run it's address in memory changes I have not been able to easily see it in the Memory watch window.

 

I'd prefer to find out why the debugger is not breaking as it should, but at this point my eyes are bleeding and I'm open to any other options on finding the leak. Anyone have any suggestions, anything would be appreciated.

Share this post


Link to post
Share on other sites
Advertisement

The problem is deterministic as each time it is the same Alloc id(147), with the same size (8 bytes, which leads me to wonder, what could i be allocating that is 8 bytes? a wchar_t maybe?).

 

Pointers are 8 bytes on a 64 bit system.  :)

I don't know why you'd dynamically allocate the pointer variable itself though, rather than the memory it points to, but that seems more likely than a single wchar_t.

Share this post


Link to post
Share on other sites

 

 

Pointers are 8 bytes on a 64 bit system.  :)

I don't know why you'd dynamically allocate the pointer variable itself though, rather than the memory it points to, but that seems more likely than a single wchar_t.

 

 

That was my initial thought(that they were pointers), but sizeof(int*) returned 4, so it threw me for a bit.

 

I have since found that since they are all created outside of main, they are allocated before the call to _CrtSetBreakAlloc() is executed, and this explains why there is no breakpoint in the debugger. This makes me think they are false positives, as they are global state objects. (I use them sparingly so i can quickly implement new ideas, which are then refactored so that the objects they require to function are passed in arguments in their constructors.)

 

However i still have no method to test this hypothesis.

Edited by Burnt_Fyr

Share this post


Link to post
Share on other sites
If you want to get really filthy...


http://www.codeguru.com/cpp/misc/misc/applicationcontrol/article.php/c6945/Running-Code-Before-and-After-Main.htm


Just abuse the CRT init segment to run a function that sets up leak checking before static initializers/main runs. I think this is still subject to the initialization order fiasco so you probably will get flaky ordering behavior, but it's a thing you could try.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!