Subject: Re: [vserver] vs2.2.0.7 + GrSec : PHP Memory leak
From: Romain Riviere <romain.riviere@gmail.com>
Date: Tue, 22 Sep 2009 14:09:02 +0200

Hello there,

2009/9/22 Herbert Poetzl <herbert@13thfloor.at>:
> On Tue, Sep 22, 2009 at 09:46:50AM +0200, Romain Riviere wrote:
>> Hello list,
>
>> I am running VServer 2.2.0.7 with Harry's GrSec/IPv6 patch, and I have
>> a nasty case of memory leak with all the versions of PHP I've tried.
>> The bug is reported at http://bugs.php.net/49501 and there is no other
>> system on which I can reproduce this.
>
> did you try without grsec/ipv6 patch?
> if so, did you try host(chroot) vs guest?
> and if, what about a vanilla kernel (same version)?

Not yet. I am building a test system but my spare time is runinng
scarce these days. However, FWIW, people running just vserver do not
exhibit the problem.
I tested in a guest, on the host, in a chroot, and got the same
results on the same host

More info now ...
Here's the typical output of "strace php test.php" on a system where
it works as expected (ie. runs in a loop until interrupted) :

---snip---
mremap(0x2aaaaacc3000, 34869248, 35917824, MREMAP_MAYMOVE) = 0x2aaaaacc3000
write(1, "35745248<br>"..., 1235745248<br>)         = 12
mremap(0x2aaaaacc3000, 35917824, 36966400, MREMAP_MAYMOVE) = 0x2aaaaacc3000
write(1, "36793824<br>"..., 1236793824<br>)         = 12
mremap(0x2aaaaacc3000, 36966400, 38014976, MREMAP_MAYMOVE) = 0x2aaaaacc3000
---snip--- (and repeat ad lib)

Here is (part of) the output of the same thing on the vserver/grsec machine :

---snip---
write(1, "2162884<br>"..., 112162884<br>)          = 11
mmap2(NULL, 1314816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x9f53c000
mremap(0x9f1ba000, 2363392, 3411968, MREMAP_MAYMOVE) = 0x9f1ba000
munmap(0x9f53c000, 1314816)             = 0
write(1, "3211460<br>"..., 113211460<br>)          = 11
mmap2(NULL, 1314816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x9f53c000
mremap(0x9f1ba000, 3411968, 4460544, MREMAP_MAYMOVE) = 0x9ed79000
munmap(0x9f53c000, 1314816)             = 0
write(1, "4260036<br>"..., 114260036<br>)          = 11
mmap2(NULL, 1314816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x9f53c000
mremap(0x9ed79000, 4460544, 5509120, MREMAP_MAYMOVE) = 0x9ed79000
munmap(0x9f53c000, 1314816)             = 0
write(1, "5308612<br>"..., 115308612<br>)          = 11
mmap2(NULL, 1314816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x9f53c000
mremap(0x9ed79000, 5509120, 6557696, MREMAP_MAYMOVE) = 0x9ed79000
munmap(0x9f53c000, 1314816)             = 0
write(1, "6357188<br>"..., 116357188<br>)          = 11
mmap2(NULL, 1314816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x1a211000)                         = 0x1a0cd000
mmap2(NULL, 1445888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 2097152, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot
allocate memory)
mmap2(NULL, 1048576, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot
allocate memory)
write(1, "\nFatal error: Out of memory (allo"..., 201
Fatal error: Out of memory (allocated 6815744) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/smokey/test.php on line 15
) = 201
munmap(0x9ed79000, 6557696)             = 0
close(0)                                = 0
munmap(0x9fcd3000, 4096)                = 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
brk(0x1a044000)                         = 0x1a044000
exit_group(255)                         = ?
---snip---

It seems to me there is a lot of extra munmap/mmap2 going on, instead
of just mremap ... could it be related to the problem at hand ?
Apart from testing a non-grsec kernel (I will get to it eventually),
what else can I do here ?

By the way, I've tried unsetting all the PaX protections from the php
binary (using chpax), and no luck either.

Many thanks,

Romain