On Wed, Jun 15, 2016 at 11:34 AM, Michael Felt <mamf...@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
