Re: die('zend_mm_heap corrupted'); // TODO: Better error message
| From: | Rowan Collins | Date: | Tue, 09 Oct 2018 08:56:27 +0000 |
| Subject: | Re: die('zend_mm_heap corrupted'); // TODO: Better error message | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-103311@lists.php.net to get a copy of this message | ||
On Tue, 9 Oct 2018 at 07:16, Dmitry Stogov <dmitry@zend.com> 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.
Regards,
--
Rowan Collins
[IMSoP]