Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94029
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHXmDMAdQS02GFw5BF_F63W5v-nGdh0CnnFJDOAj9c6hKy9zMA@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>
Date: Wed, 15 Jun 2016 20:21:53 -0400
Message-ID: <CADS+g1rWvCmLcr2tuHWS+5sPinO7n+cKqPZfGg-wogcGoNbbVw@mail.gmail.com>
To: Trevor Suarez <rican7@gmail.com>
Cc: Michael Felt <mamfelt@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1558e6303c505355a3b59
Subject: Re: [PHP-DEV] PHP allocating too much memory
From: peterlebrun@gmail.com (Peter LeBrun)

--001a11c1558e6303c505355a3b59
Content-Type: text/plain; charset=UTF-8

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.

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
>

--001a11c1558e6303c505355a3b59--