Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94032
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADS+g1rWvCmLcr2tuHWS+5sPinO7n+cKqPZfGg-wogcGoNbbVw@mail.gmail.com>
References: <CADS+g1pFGsuv5Tfz9a_exmycBKuo4K8erfsWZKySSbtWEnHFhQ@mail.gmail.com>
	<4771c925-65e1-536f-e573-250dc99f2e39@gmail.com>
	<0e11e396-48be-ae7d-4a7a-8b964d2cf128@gmail.com>
	<CAHXmDMAdQS02GFw5BF_F63W5v-nGdh0CnnFJDOAj9c6hKy9zMA@mail.gmail.com>
	<CADS+g1rWvCmLcr2tuHWS+5sPinO7n+cKqPZfGg-wogcGoNbbVw@mail.gmail.com>
Date: Thu, 16 Jun 2016 10:11:38 +0700
Message-ID: <CAEZPtU70v73UB=PyE3KwM3FRWqM=Ppq6JTyi=Yqf4SHT_xcQBA@mail.gmail.com>
To: Peter LeBrun <peterlebrun@gmail.com>
Cc: Trevor Suarez <rican7@gmail.com>, Michael Felt <mamfelt@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c04f718ac555505355c98b5
Subject: Re: [PHP-DEV] PHP allocating too much memory
From: pierre.php@gmail.com (Pierre Joye)

--94eb2c04f718ac555505355c98b5
Content-Type: text/plain; charset=UTF-8

Hi

On Jun 16, 2016 7:22 AM, "Peter LeBrun" <peterlebrun@gmail.com> wrote:
>
> Hey everyone, thanks for your help and input.  We've narrowed it down to
> cases where there is string concatenation with a constant, but currently
> upgrading to 7.0.7 to see if that makes a difference.

Is it possible to open a bug or post a reproduce script here please?

> Enjoy your evening,
>
> Peter
>
> On Wed, Jun 15, 2016 at 1:50 PM, Trevor Suarez <rican7@gmail.com> wrote:
>
> > On Wed, Jun 15, 2016 at 11:34 AM, Michael Felt <mamfelt@gmail.com>
wrote:
> >
> > >
> > >
> > > On 15-Jun-16 15:55, Rowan Collins wrote:
> > >
> > >> On 15/06/2016 14:01, Peter LeBrun wrote:
> > >>
> > >>> The weirdest part about this is that PHP is somehow trying to
allocate
> > >>> 140TB of memory.
> > >>>
> > >>
> > >> I've seen numbers like that a few times - always around 140TB, but
the
> > >> exact number varies. I assume it's an overflow (or underflow?)
> > somewhere,
> > >> but the exact mechanism escapes me. (It's close to 2^47, but not very
> > >> close; I've got examples logged as "low" as 140090229815192, and I
think
> > >> I've seen under 140 trillion.)
> > >>
> > > In hex: 00007F694C627798 - so apparently 00007F69400000000 is common
to
> > > all.
> > > FYI: I have seen similar issues with mixed environments (32 and
64-bit) -
> > > at this point I am surprised that you can even dlopen() both sizes
(my OS
> > > now refuses to dlopen() 32-bit modules aka shared libraries when
64-bit
> > > application and v.v.)
> > >
> > >> Apart from sheer curiosity of where this magic number comes from, I
> > >> wonder if there is some sanity check missing in the memory manager
to at
> > >> least display a different error message...
> > >>
> > >> Regards,
> > >>
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> > I've seen this bug come up with the SOAP extension. I saw it happen when
> > instantiating a SoapClient or SoapServer when the constructor tries to
load
> > a WSDL file under very certain circumstances. If the SOAP WSDL caching
is
> > on (if `soap.wsdl_cache = 1`), the WSDL file is cached (or is
attempting to
> > be cached) or the WSDL must be downloaded, and the file-system is full,
> > then this crazy overflow can happen. I believe it's due to the WSDL's
> > becoming corrupted due to the file-system halting the write of the file
and
> > PHP not cleaning up the improper write.
> >
> > In fact, this is a reported bug: https://bugs.php.net/bug.php?id=62337
> >
> > Hope that helps! :)
> >
> > - Trevor
> >

--94eb2c04f718ac555505355c98b5--