Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103411 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21880 invoked from network); 30 Oct 2018 19:46:15 -0000 Received: from unknown (HELO v-smtpout1.han.skanova.net) (81.236.60.154) by pb1.pair.com with SMTP; 30 Oct 2018 19:46:15 -0000 Received: from [192.168.8.9] ([94.254.95.82]) by cmsmtp with ESMTPA id HWTmgkAEBONS2HWTmgnR9H; Tue, 30 Oct 2018 17:02:54 +0100 To: Julien Pauli , Rowan Collins , Dmitry Stogov Cc: PHP Internals References: Message-ID: <6b1af832-42f7-5176-de97-5f47d1354aca@telia.com> Date: Tue, 30 Oct 2018 17:02:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-CMAE-Envelope: MS4wfLHmRRF82Jx35T00p7wvInJawTeqnZ3QCfZuqNl490SV4ZPPpqcTDzYhL/eJfrf627o7RvIJKBCNES1udzHVuLtXgDAlOQjTYZXnDQrZSlp4LJuFy8SC V3ffQWvqps7yt75spO396sRCdgO8Qyb0vrRRW5bPDq8DnVKK4Zu94eWcqeeE4JQYn4y6m0cDFEtHWCxQ7X2UyuK91nLJQ9mCOZBwhWEKR3vxR3nbPesrwmvJ ViuC+jTQkkQ/5Gv23bYIixagNoCeohlg4eLzrGqL224= Subject: Re: [PHP-DEV] die('zend_mm_heap corrupted'); // TODO: Better error message From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=) Den 2018-10-11 kl. 23:25, skrev Julien Pauli: > On Tue, Oct 9, 2018 at 10:56 AM Rowan Collins > wrote: > >> On Tue, 9 Oct 2018 at 07:16, Dmitry Stogov wrote: >> >>> Hi Rowan, >>> >>> >>> This error message is triggered when Zend MM used in improper way, e.g. >>> invalid pointer free, etc. >>> >>> MM can't provide useful information about the context and reason. >>> >> >> I get that it can't provide the *reason*, but that doesn't mean there can't >> be any *context*: >> >> - Will it always occur during shutdown? If so, the message could include >> "during shutdown". If not, could the message indicate whether it is or not? >> - The ZEND_MM_CHECK macro takes a message, but all 15 uses of it pass the >> same message, "zend_mm_heap corrupted"; are they really identical? Could >> making each message distinct help improve bug reports? >> - The printf format in zend_mm_panic could add something other than a >> newline, e.g. "PHP Engine Error: %s", to make this line clearer in the logs >> to people who have never heard of "Zend MM". >> - Ideally, it would also include a timestamp; without this, it can be very >> hard to line up which requests are failing, or even how often it is >> happening. >> >> So, rather than the current message: >> >> zend_mm_heap corrupted >> >> It would be great to see: >> >> [09-Oct-2018 09:33:03 Europe/London] PHP Fatal Error: zend_mm_heap >> corrupted (invalid page offset) during process shutdown. >> >> Even better would be for this to drop into the PHP error log, rather than >> echoing to stderr, but I realise that might be more complicated during a >> "panic" scenario like this. >> >> >> >> >>> The best way to find the reason of the problem is running php under >>> valgrind. >>> >>> >>> $ USE_ZEND_ALLOC=0 valgrind php ... >>> >>> >>> In most cases valgrind will show incorrect MM operations and their >> history. >> >> I'm not proficient enough with C to get far with that, so my main concerns >> are 1) ensuring these errors are clearly visible in the logs; and 2) >> helping provide useful context in a bug report against core or an >> extension. >> > > I think we can improve a little bit, but seeing this message , basically > means that all the memory image (heap) of the current PHP process is > corrupted. > > That means that we cannot access any memory area safely, so that means : we > can't call for a function in PHP (like the traditionnal log function, that > would lead to a nice formatted error message). > The only thing we can do, is exit the process. Any attempts to continue > running it, will crash it for sure as crucial memory areas have been > corrupted. > > We are in the last low level code area before exiting here, when MM is > paniced , its like the Earth is beeing destroyed : you have no other choice > of waiting your own death, or shorten it by killing yourself. > What we could do , is create a little safe memory zone at PHP startup, > wherein we could live when ZendMM is paniced, and we could try to do better > things than just printf() to stderr and exit. > > This ZendMM Panic message is the worst situation PHP could live in. You > should immediately turn off external extensions leading to such a message. > By activating them one by one, you'll find the guilty one I'm sure ^^ > > After, if you can get a reproducer, then GDB will tell you any little piece > of thing you'd like to know about when crashing ;-) > > If you dont want Apache to dumbly give up with the current request, you > should separate your processes by running php-fpm. > This way, you'll get an answer from Apache, like a 503 or so , and probably > some logs in php-fpm logs. > > > Julien.Pauli > Would it then be possible to improve printf output a little by including time & date and stating it's a PHP engine error? r//Björn L