Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94019
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0e11e396-48be-ae7d-4a7a-8b964d2cf128@gmail.com>
References: <CADS+g1pFGsuv5Tfz9a_exmycBKuo4K8erfsWZKySSbtWEnHFhQ@mail.gmail.com>
 <4771c925-65e1-536f-e573-250dc99f2e39@gmail.com> <0e11e396-48be-ae7d-4a7a-8b964d2cf128@gmail.com>
Date: Wed, 15 Jun 2016 13:50:58 -0400
Message-ID: <CAHXmDMAdQS02GFw5BF_F63W5v-nGdh0CnnFJDOAj9c6hKy9zMA@mail.gmail.com>
To: Michael Felt <mamfelt@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11474e78a3dc23053554c3a0
Subject: Re: [PHP-DEV] PHP allocating too much memory
From: rican7@gmail.com (Trevor Suarez)

--001a11474e78a3dc23053554c3a0
Content-Type: text/plain; charset=UTF-8

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

--001a11474e78a3dc23053554c3a0--