Skip to main content
GameDev.net gamedev.net
🔒 Locked

_CrtSetBreakAlloc() not breaking

Started by Burnt_Fyr Sep 25, 2016 at 1:43 AM 2 replies 4.3k views
Original Post
Burnt_Fyr
Burnt_Fyr

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.

Servant of the Lord
Servant of the Lord

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.

Burnt_Fyr
Burnt_Fyr

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.

ApochPiQ
ApochPiQ
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.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.