Conflict with _CRTDBG_MAP_ALLOC (Visual Studio)


#1

I tried to include the Juce header in one of my projects, but I’m getting caught up on juce_HeapBlock.h. The problem is that I define _CRTDBG_MAP_ALLOC, which turns malloc() into a macro, causing juce_HeapBlock.h to produce compile errors. I could turn off this #define but then I would lose standard-library level leak checking for a lot of existing code that uses malloc().

I don’t really see a way around it other than renaming the methods in juce::HeapBlock to not conflict with standard C library function names.


#2

#undef before including juce ?


#3

That is the same as just turning off _CRTDBG_MAP_ALLOC, which means no debug leak checking for the standard library calls.


#4

You could undef it before including juce, and then re-def it afterwards?


#5

Okay there seems to be some misunderstanding of how this thing works. What you do is #define _CRTDBG_MAP_ALLOC before including standard headers like <memory.h>. This causes those header files to create macros for malloc() that generate calls to _dbg_malloc() and what not, with the file and line number as parameters for leak reporting.

Once you define _CRTDBG_MAP_ALLOC and include <memory.h>, #undef of _CRTDBG_MAP_ALLOC doesn’t do anything. You could #undef malloc but then redefining it would be a hassle.

I’m amazed that no one else has run into this problem…am I the only one who uses the Visual Studio debug heap features??!


#6

I’ve always used the debug allocator, but only by calling the _dbg_malloc directly. #defining malloc is just asking for trouble!


#7

I hear you but thats how MSVC implemented it. Maybe we can rename your functions, i.e. HeapBlock::jmalloc() ?


#8

Sorry, I ain’t compromising my lovely code because of MFC’s stoopid design!

Did you know there’s a #pragma push_macro/pop_macro? You could use those either side of juce to save and restore all the malloc macros.


#9

That is a good solution, I will use it.


#10

I ran into the exact same problem, thanks! Took me a little while to find the macros so I thought I’d share. I also redefined ‘new’ to give trace information.

EDIT: Redefining ‘new’ causes problems as soon as you overload the ‘new’ operator so I removed it from the code below.

[code]#if _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

#pragma push_macro("calloc")
#pragma push_macro("free")
#pragma push_macro("malloc")
#pragma push_macro("realloc")
#pragma push_macro("_recalloc")
#pragma push_macro("_aligned_free")
#pragma push_macro("_aligned_malloc")
#pragma push_macro("_aligned_offset_malloc")
#pragma push_macro("_aligned_realloc")
#pragma push_macro("_aligned_recalloc")
#pragma push_macro("_aligned_offset_realloc")
#pragma push_macro("_aligned_offset_recalloc")
#pragma push_macro("_aligned_msize")

#undef calloc
#undef free
#undef malloc
#undef realloc
#undef _recalloc
#undef _aligned_free
#undef _aligned_malloc
#undef _aligned_offset_malloc
#undef _aligned_realloc
#undef _aligned_recalloc
#undef _aligned_offset_realloc
#undef _aligned_offset_recalloc
#undef _aligned_msize

#include "juce.h"

#pragma pop_macro("_aligned_msize")
#pragma pop_macro("_aligned_offset_recalloc")
#pragma pop_macro("_aligned_offset_realloc")
#pragma pop_macro("_aligned_recalloc")
#pragma pop_macro("_aligned_realloc")
#pragma pop_macro("_aligned_offset_malloc")
#pragma pop_macro("_aligned_malloc")
#pragma pop_macro("_aligned_free")
#pragma pop_macro("_recalloc")
#pragma pop_macro("realloc")
#pragma pop_macro("malloc")
#pragma pop_macro("free")
#pragma pop_macro("calloc")

#else
#include “juce.h”
#endif[/code]


#11

Hi there,
I want to reply to this post because it is real that using reserved keyword in JUCE is quite a bad idea.
For example, I am in the case that I have a memory leak that pop out from nowhere using “Detected memory leaks !” scheme and I cannot use _CRTDBG_MAP_ALLOC flag to know from where bug starts.
In those (rare) cases, the use of reserved keywords in JUCE is a real pain in the ass.
For future release, could you consider modifying this kind of habit please ?
Best regards.

P.S. : that is not a complain or something like that, I do not want to make you sad or angry, I just point out a fact that can be really difficult to pass through.


#12

Just hit this today. Kind of a bummer. Yes, macroing malloc is pretty awful, but you can see why they did it.

Why not have HeapBlock::allocate, reallocate, and deallocate? (Like std::allocator)