That bit of C code should not leak, if it does, the memory allocation algorithms are quite broken on your system. As for Xdebug specifically, please provide a short reproducible script to show that Xdebug leaks.

The leaks have been inside when using VC6, VC8, VC9 compilers. Have you ever used any kind of leak detectors ? If not, I suggest to use one... As I already mentioned the culprit is using macros inside macro. See my first description where I use C code to produce leak. This is the same memory allocation code you use in XDebug. In function LeakTest() every line of code causes memory to be allocated twice! 1) compiler resolves MACRO, 2) compiler resolves MACRO inside MACRO

Macros are resolved by the compiler and have nothing to do with runtime code. During runtime, the memory is only allocated once. Yes, I have used leak detectors (on Linux) and it's fine (at least for this general case).

That bit of C code should not leak, if it does, the memory allocation algorithms are quite broken on your system. As for Xdebug specifically, please provide a short reproducible script to show that Xdebug leaks.

Here you go. Below is a Windows example which uses debug runtime macros to report memory leaks. It will produce 2 leaks, both 13 bytes long.
As I already mentioned: see your memory allocation MACROS!

#include <windows.h>
#include <Crtdbg.h>

#define xdstrdup strdup
#define xdfree free

void print_text_and_free_ex(char *text, int length);

#define print_text_and_free(t) \
print_text_and_free_ex( (t), strlen(t) )

void print_text_and_free_ex(char *text, int length)
{
printf( "text: %s, length: %d\n", text, length );
xdfree( text );
}

void LeakTest()
{
print_text_and_free( xdstrdup("XDEBUG leak1") );
print_text_and_free( xdstrdup("XDEBUG leak2") );
}

int main(int argc, char* argv[])
{
#ifdef _DEBUG
DWORD memoryDebugFlag;
SECURITY_ATTRIBUTES securityAtts;
char buf[64];
HANDLE memory_leak_file;

securityAtts.nLength = sizeof( SECURITY_ATTRIBUTES );
securityAtts.lpSecurityDescriptor = ((LPVOID)0);
securityAtts.bInheritHandle = FALSE;

sprintf( buf, "c:\\mem_leak_%d.txt", GetCurrentProcessId() );
memory_leak_file = CreateFile( buf, GENERIC_WRITE, FILE_SHARE_READ, &securityAtts, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, ((HANDLE)0) );
if( memory_leak_file == INVALID_HANDLE_VALUE ) {
    printf( "CreateFile failed, error: %d\n", GetLastError() );
    exit( -1 );
}

_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_WARN, memory_leak_file );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ERROR, memory_leak_file );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ASSERT, memory_leak_file );

memoryDebugFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
memoryDebugFlag |= _CRTDBG_LEAK_CHECK_DF;
memoryDebugFlag |= _CRTDBG_DELAY_FREE_MEM_DF;
_CrtSetDbgFlag( memoryDebugFlag );

#endif / #ifdef _DEBUG/

LeakTest();

return 0;

}

Duh, it took me some time to realize that due that the macro expanded to:

print_text_and_free_ex( (xdstrdup("TEST1")), strlen(xdstrdup("TEST1")) )

That has little to do with macros inside a macro though. Anyway, it's fixed in CVS now. There are two tiny (2x 2 bytes) leaks left, but they only happen when starting/shutting down and are not repeatable.