Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.

Hi,
After emailing to php-dev and fixing my code I've got rid of the error.
Problem is that I've thought that PHP will handle concurrent stuff so
I don't need to.
My problem was having code that does something like this:
fopen($fp,"file.php");
fputs($fp,"<?php /*code*/ ?>");
fclose($fp);
And also in other parts of code to have:
include("file.php");
Which caused sometimes the include have a broken file. I still think that crashing to broken file is not acceptable behavior, but I've understood that you can crash PHP by coding something wrong and PHP doesn't protect you or crash nicely. Which can be problem in hosted environment if not running basic PHP-CGI for every request.
I think include/require documentation should have warning box saying something that you have to handle concurrent stuff and/or PHP can crash to broken PHP files without nice error. I think that might helped me.
For the fix in my code was to change my writing to file:
fopen($fp,"file.php.tmp.".getmypid());
fputs($fp,"<?php /*code*/ ?>");
fclose($fp);
rename("file.php.tmp.".getmypid(),"file.php");
Pretty easy fix if you know that you have to do it or expect PHP to crash to broken files.
Of course I can't say anything about the other crashes, but as the backtraces seem similar and the example code to used to crash PHP has similar problem might that help.

I am still encountering this bug with PHP 5.5.9, using php5-fpm without opcache/APC.
Backtrace:
#0 lex_scan (zendlval=zendlval@entry=0x7fffefa33e58) at Zend/zend_language_scanner.c:2271
#1 0x00000000006d7772 in zendlex (zendlval=zendlval@entry=0x7fffefa33e50) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_compile.c:6749
#2 0x00000000006b2766 in zendparse () at /build/buildd/php5-5.5.9+dfsg/Zend/zend_language_parser.c:3438
#3 0x00000000006b7d18 in compile_file (file_handle=file_handle@entry=0x7fffefa36330, type=8) at Zend/zend_language_scanner.l:588
#4 0x00000000006dd4ea in dtrace_compile_file (file_handle=0x7fffefa36330, type=<optimized out>)
at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:40
#5 0x0000000000566674 in phar_compile_file (file_handle=<optimized out>, type=<optimized out>)
at /build/buildd/php5-5.5.9+dfsg/ext/phar/phar.c:3379
#6 0x000000000079cb9d in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (execute_data=0x7fc1d68e6688)
at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:7994
#7 0x00000000007173e8 in execute_ex (execute_data=0x7fc1d68e6688) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#8 0x00000000006dd559 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#9 0x000000000079d1bf in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (execute_data=0x7fc1d68e60f8)
at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:2748
#10 0x00000000007173e8 in execute_ex (execute_data=0x7fc1d68e60f8) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#11 0x00000000006dd559 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#12 0x00000000006eefe0 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3)
at /build/buildd/php5-5.5.9+dfsg/Zend/zend.c:1316
#13 0x000000000068eec5 in php_execute_script (primary_file=primary_file@entry=0x7fffefa38ad0)
at /build/buildd/php5-5.5.9+dfsg/main/main.c:2506
#14 0x0000000000463b00 in main (argc=<optimized out>, argv=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/sapi/fpm/fpm/fpm_main.c:1933
Line 2271 is this switch statement:
YYDEBUG(121, *YYCURSOR);
YYFILL(16);
yych = *YYCURSOR;
YYDEBUG(-1, yych);
2271 switch (yych) {
case 0x00:
case 0x01:
case 0x02:
case 0x03:
This bug is marked duplicate, but all of the references bugs also appear to be marked duplicate.
The error does not happen on every request, but occurs several ten or so times a day on our webserver. The file being compiled is "/var/www/include/include.php", which is included on every request, so there does not appear to be anything special about the requests that are failing (usually it is just a GET request for a static page that's parsed through PHP).

I can repro using the script provided by paulgao
<?php
file_put_contents(__DIR__ . '/test.tpl', 'AAA<?php $string = "'. str_repeat('A', mt_rand(1, 256 * 1024)) .'"; ?>BBB' . "\r\n");
require_once __DIR__ . '/test.tpl';
together with
for ((n=0;n<100;n++)); do sapi/cli/php test.php & done
A few of the PHP processes will trigger a SIGBUS.
The issue here seems pretty clear. We are mmap()ing the file. While the file is mapped, it is modified, resulting in an effective ftruncate(). Here is what the man page for ftruncate() has to say on the topic:
> If the effect of ftruncate() is to decrease the size of a shared memory object or memory mapped file and whole pages beyond the new end were previously mapped, then the whole pages beyond the new end shall be discarded.
>
> If the Memory Protection option is supported, references to discarded pages shall result in the generation of a SIGBUS signal; otherwise, the result of such references is undefined.
This is precisely what we are observing here.
I don't think there is any good way of fixing this short of dropping the mmap() and reading the file into memory instead (which we already do in the fallback code).

Wouldn't acquiring a shared lock work here? We only lex when including an uncached file, so the extra flock() hit would be negligible over time (except for scripts like this which void assumptions about file permanence, obviously).

[2017-06-02 14:12 UTC] blazej dot adamczyk at gmail dot com

+1 for the flock.
Alternatively another way would be to handle the SIGBUS and recover from such situation.

It seems to be over-allocating on the stack.
Let's see if we can narrow the problem down to finding the file that's causing the problem.
In gbd, jump to frame 5 and print file_handle as well as file_handle as well as file_handle->filename and file_handle->opened_path
(gdb) f 5
(gdb) p file_handle
(gdb) p file_handle->filename
(gdb) p file_handle->opened_path

Anyone have any ideas? this is a pretty long standing bug that is still evident in current PHP. We're getting hit by it pretty hard in production so I'm interested in any options possible. In the meantime, I've had to hack up PHP not to use mmap() for file io.

Also reproducible on Amazon Linux PHP 5.6.36. Our production httpds also crash every day.

[2018-07-10 12:04 UTC] maroszek at gmx dot net

This is still an issue on PHP 7.2 on any linux system we use. (We are using embed SAPI with disable-zend-signals)
Is there anything I can do to help tackle the issue? Can we update the version information to PHP 7.2?