Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94014
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
To: internals@lists.php.net
References: <CADS+g1pFGsuv5Tfz9a_exmycBKuo4K8erfsWZKySSbtWEnHFhQ@mail.gmail.com>
 <4771c925-65e1-536f-e573-250dc99f2e39@gmail.com>
Message-ID: <0e11e396-48be-ae7d-4a7a-8b964d2cf128@gmail.com>
Date: Wed, 15 Jun 2016 17:34:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <4771c925-65e1-536f-e573-250dc99f2e39@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP allocating too much memory
From: mamfelt@gmail.com (Michael Felt)



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,