View Issue Details

IDProjectCategoryView StatusLast Update
0000453XdebugUncategorizedpublic2009-09-06 23:05
Reportertrekker Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version2.0.0dev 
Summary0000453: Memory Leaks
Description

I wonder why nobody ever reported XDebug memory leaks. These leaks have been inside of XDebug for years. Every time I upgrade I have to make a major leak cleanup. Never use memory allocation MACROS inside MACRO! Take a look on the following simple script. It will cause leaks, and so does XDebug...

#define xdstrdup strdup
#define xdfree free

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

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

void LeakTest()
{
print_text_and_free( xdstrdup("TEST1") );
print_text_and_free( xdstrdup("TEST2") );
}

Additional Information

Detected memory leaks!
Dumping objects ->
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15652} normal block at 0x0328CCB0, 2 bytes long.
Data: <1 > 31 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug.c(2603) : {15623} normal block at 0x0328BCC0, 24 bytes long.
Data: <Content-type: te> 43 6F 6E 74 65 6E 74 2D 74 79 70 65 3A 20 74 65
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15612} normal block at 0x0328B8B0, 2 bytes long.
Data: <1 > 31 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2579) : {15590} normal block at 0x0328AAA8, 45 bytes long.
Data: <Maximum executio> 4D 61 78 69 6D 75 6D 20 65 78 65 63 75 74 69 6F
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15493} normal block at 0x03287EF8, 2 bytes long.
Data: <1 > 31 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15467} normal block at 0x03286F80, 2 bytes long.
Data: <1 > 31 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15442} normal block at 0x03286098, 2 bytes long.
Data: <1 > 31 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15416} normal block at 0x03285160, 2 bytes long.
Data: <1 > 31 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(1156) : {15381} normal block at 0x03284048, 8 bytes long.
Data: <Warning > 57 61 72 6E 69 6E 67 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15376} normal block at 0x03283EB0, 3 bytes long.
Data: <28 > 32 38 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(1156) : {15340} normal block at 0x03282D08, 12 bytes long.
Data: <Fatal error > 46 61 74 61 6C 20 65 72 72 6F 72 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2239) : {15335} normal block at 0x03282B70, 3 bytes long.
Data: <28 > 32 38 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2361) : {14965} normal block at 0x0327AC48, 42 bytes long.
Data: <Copyright (c) 20> 43 6F 70 79 72 69 67 68 74 20 28 63 29 20 32 30
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2357) : {14961} normal block at 0x0327AB00, 18 bytes long.
Data: <http://xdebug.or> 68 74 74 70 3A 2F 2F 78 64 65 62 75 67 2E 6F 72
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2353) : {14957} normal block at 0x0327A9B8, 15 bytes long.
Data: <Derick Rethans > 44 65 72 69 63 6B 20 52 65 74 68 61 6E 73 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_handler_dbgp.c(2349) : {14953} normal block at 0x0327A880, 7 bytes long.
Data: <Xdebug > 58 64 65 62 75 67 00
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug.c(2603) : {14946} normal block at 0x0327A608, 79 bytes long.
Data: <Set-Cookie: XDEB> 53 65 74 2D 43 6F 6F 6B 69 65 3A 20 58 44 45 42
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_str.c(106) : {14920} normal block at 0x03279BC8, 25 bytes long.
Data: </tmp/trace.40551> 2F 74 6D 70 2F 74 72 61 63 65 2E 34 30 35 35 31
h:\work\mysql\php\php-5.3.0\ext\xdebug\xdebug_str.c(51) : {14913} normal block at 0x03279678, 1025 bytes long.
Data: <trace.4055188278> 74 72 61 63 65 2E 34 30 35 35 31 38 38 32 37 38

TagsNo tags attached.
Operating System
PHP Version5.3.0

Activities

derick

2009-08-01 17:38

administrator   ~0001018

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.

trekker

2009-08-17 06:44

reporter   ~0001041

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

derick

2009-08-22 13:26

administrator   ~0001049

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.

trekker

2009-08-27 11:46

reporter   ~0001058

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, &quot;c:\\mem_leak_%d.txt&quot;, 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( &quot;CreateFile failed, error: %d\n&quot;, 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;

}

derick

2009-09-06 23:05

administrator   ~0001065

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.

Issue History

Date Modified Username Field Change
2009-07-17 12:21 trekker New Issue
2009-07-17 12:21 trekker PHP Version => 5.3.0
2009-07-17 12:21 trekker Xdebug Version => 2.0.5
2009-08-01 17:38 derick Note Added: 0001018
2009-08-01 17:38 derick Status new => feedback
2009-08-17 06:44 trekker Note Added: 0001041
2009-08-22 13:26 derick Note Added: 0001049
2009-08-27 11:46 trekker Note Added: 0001058
2009-09-06 23:05 derick Note Added: 0001065
2009-09-06 23:05 derick Status feedback => closed
2009-09-06 23:05 derick Resolution open => fixed
2016-07-31 12:36 derick Category Usage problems => Usage problems (Crashes)
2016-07-31 12:38 derick Category Usage problems (Crashes) => Usage problems (Wrong Results)
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized