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.


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.


Thanks. Dmitry.

________________________________
From: Rowan Collins <rowan.coll...@gmail.com>
Sent: Monday, October 8, 2018 1:17:06 PM
To: PHP internals
Subject: [PHP-DEV] die('zend_mm_heap corrupted'); // TODO: Better error message

Hi all,

We recently had an error in production which was hard to reproduce, hard to
debug, and turned out to be a bug in an extension. One of the oddest
symptoms was that the PHP code seemed to run to completion, but the request
was never logged by Apache.

The only thing logged was the words "zend_mm_heap corrupted", in the Apache
error log. As far as I can see, this ultimately comes from zend_mm_panic
[1], which (on non-Windows non-debug builds) is simply:

fprintf(stderr, "%s\n", message);
exit(1);

Frustratingly, this error:

- Doesn't contain a timestamp
- Doesn't contain any context of where the error happened (not even a hint
that this happened during shutdown rather than execution)
- Doesn't mention PHP, or look like the messages PHP would normally log
- Doesn't log to the PHP error log
- Doesn't register as an error in Apache itself

The server in question was running PHP as an Apache module in pre-fork
mode; in that configuration, stderr gets slurped into the Apache error log
without annotation, and the exit(1) silently terminates the connection and
logs nothing.

I suspect this is one of those last-ditch errors where there is a risk of
causing further errors if global data is accessed, but is there any way
this message can be improved, at least to format it more like other PHP
errors?


[1]
https://github.com/php/php-src/blob/1154f6f70a3e4ee083f1bc42d83c190ad68f3862/Zend/zend_alloc.c#L348

Regards,
--
Rowan Collins
[IMSoP]

Reply via email to