The last line of the initial description should have read : PHP compiled --with-pic.

For the record, the problem appeared in Drupal and was reported as happening at zend_opcode.c:48. However, since it can obviously be reproduced with something as simple as a string, I believe it is a more general memory leak issue.

Are you saying you don't see it if you don't use --with-pic?

And I am curious, why do you want pic?  libphp5.so isn't a general-purpose shared library that can be linked into many different things.  It is a very targeted library compiled for a specific binary to link and as such compiling it pic just adds unnecessary overhead.

I'm mentioning pic because it is the only thing slightly out of the ordinary in this setup.

I am using pic because of disabled TEXTRELs in the PaX enabled kernel. I'm willing to try without pic though. I'll add to this report in case it changes anything.

Just to confirm: the problem is still present without pic.

You also seem to be using --enable-debug, does it happen without it? And can you reproduce the same on command line?

The problem still happens without --enable-debug.

I could reproduce the bug in CLI with a simple while(true). More specifically (and with memory_limit=128M this time):

<?php
ini_set('display_errors',true);
if (isset($_GET['size']) && $_GET['size'] < 200) {
$mb = intval($_GET['size']);
}
else {
        $mb=125;
}

while(true) {
$var = '';
echo 'Memory limit: '.ini_get('memory_limit').'<br>';
for ($i=0; $i<=$mb; $i++) {
        $var.= str_repeat('a',1*1024*1024);
        echo memory_get_usage().'<br>';
}
echo 'String length: '. strlen($var);
}
?>

This script crashes after a few iterations with the message:

Fatal error: Out of memory (allocated 123469824) (tried to allocate 122683393 bytes) in /home/acrm/OF-svn/2.0/test.php on line 14
zend_mm_heap corrupted

The memory_get_usage() output increases until it busts the 128M limit.

Now, I'm not too familiar with PHP's memory management, but I find it strange that the script should hog memory that way: shouldn't it free some RAM when $var is reset to '' ?

At any rate, the initial issue remains, whether this one is related or not.

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I can not reproduce this at all on several different servers running 
latest svn checkout.

And make sure you really do simply this:

1. Unpack sources
2. ./configure --disable-all --disable-cgi && make
3 run the test script with 'sapi/cli/php -n -d memory_limit=128M 
yourscript.php

I was able to reproduce the problem even with the latest sources. I am beginning to suspect PaX/GrSecurity.

Are there any catches to be aware of when running PHP in that context ? I know of the --with-pic/TEXTREL issue, but apparently there must be something else to it.

Unfortunately, same difference (Fatal error: Out of memory (allocated 9175040) (tried to allocate 1048577 bytes) in /home/smokey/test.php on line 15).

I need to take some time and experiment a different kernel, with different combinations of VServer/PaX/Grsecurity options, and see if it helps.

Just a quick follow-up on this one.

I've finally traced it to PaX's SEGMEXEC feature.
I do not know yet if every PaX kernel should display that behaviour, or if it's just VServer's GrSec patch, but disabling SEGMEXEC fixed it for me.

I guess the bottomline here is : not PHP's fault

Cheers !

Due to VMA mirroring, the SEGMEXEC option causes accounted vm usage to double.  So you weren't experiencing a memory leak -- you were just being accounted for twice as much memory as you thought you were using.  The solution would be to double the resource limit or, if your system is NX-capable and PAE is enabled, use PAGEEXEC.

-Brad

Brad, thanks for clearing that up. However, I'm not sure I understand how it explains the behaviour I've had: shouldn't the memory allocation give up when reaching about half of the allowed 128M ? It's far from being the case here ...

Without SEGMEXEC: the code (second snip) used to demonstrate the bug runs in an endless loop, as it is supposed to. The string never exceeds PHP's memory limit.

With SEGMEXEC: the code runs a few times, meaning the string is generated up to PHP's memory limit. However, after a few runs, it dies, and it's never even close to half the memory_limit.

What am I missing ?

.