Re: [vserver] vs2.2.0.7 + GrSec : PHP Memory leak [SOLVED]

From: Natanael Copa <natanael.copa_at_gmail.com>
Date: Wed 30 Sep 2009 - 06:54:55 BST
Message-Id: <1254290095.22118.10.camel@ncopa-desktop.nor.wtbts.net>

On Tue, 2009-09-29 at 19:36 +0200, Romain Riviere wrote:
> Hello there,
>
> More feedback on this nasty issue : it's *SOLVED* ! The bad news is, I
> can blame it on the VServer+GrSec patch. The good news is, it's just
> the grsec part.
>
> After perusing the patch source a little, I had a hunch that PaX was
> interfering here, especially SEGMEXEC. And what do you know, one
> kernel with CONFIG_PAX_SEGMEXEC unset later, PHP is happily using
> exactly the amount of memory it should.
>
> Further debugging is not exactly in my league :-)

Does this affect the grsecurity alone or does it only affect the vserver
+grsecurity combo?

Did you report it back to the grsecurity maintainers?

-nc

> Cheers,
>
> Romain
>
> Le 22 sept. 2009 à 14:09, Romain Riviere a écrit :
>
> > 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
>
Received on Wed Sep 30 06:52:33 2009

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 30 Sep 2009 - 06:52:37 BST by hypermail 2.1.8