Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Why would one use cygwin if there is a native build? Besides that, a backtrace is 
needed.

(gdb) bt
#0  lex_scan (zendlval=zendlval@entry=0x285888) at 
Zend/zend_language_scanner.c:1091
#1  0x006e840f in zendlex (zendlval=zendlval@entry=0x285880) at /install/php-
5.5.1/Zend/zend_compile.c:6777
#2  0x006c2f0e in zendparse () at /install/php-
5.5.1/Zend/zend_language_parser.c:3436
#3  0x006c98f2 in compile_file (file_handle=0x289944, type=8) at 
Zend/zend_language_scanner.l:588
#4  0x005a0c72 in phar_compile_file (file_handle=0x289944, type=8) at 
/install/php-5.5.1/ext/phar/phar.c:3388
#5  0x006fe22d in zend_execute_scripts (type=type@entry=8, 
retval=retval@entry=0x0, file_count=file_count@entry=3) at /install/php-
5.5.1/Zend/zend.c:1308
#6  0x0069fa4c in php_execute_script (primary_file=primary_file@entry=0x289944) 
at /install/php-5.5.1/main/main.c:2484
#7  0x007a249b in do_cli (argc=argc@entry=2, argv=0xb965ba 
<long_min_digits+726>, argv@entry=0x28ac1c) at /install/php-
5.5.1/sapi/cli/php_cli.c:994
#8  0x007b1e6c in main (argc=2, argv=0x28ac1c) at /install/php-
5.5.1/sapi/cli/php_cli.c:1378
(gdb)


One would rather need php in cygwin environment than need cygwin to run php.

Please try to disable phar and see if something change.

Btw, you don't need cygwin to run php. If you just put it on the cygwin path, 
shouldn't it work? Well, cygwin paths might do a mess though.

Hi again. Could you please also post the ./configure arguments?

This bug might be not related to phar or your particular 
environment. Looking through the bug tracker I find your backtrace is related to 
bug #65091, bug #52752, bug #65091, bug #64883 and maybe bug #61186

see bug #52752

This also occurs with a file size of 8192 bytes!

PHP mmap()s source files as it it faster than using normal I/O.

The problem is with the page size in Cygwin. When a file is mmap()ed to memory, any remaining bytes after the EOF in the last page are zero'ed out. So when PHP reads the bytes after the EOF, it expects to find zeroes.

In most systems the page size is 4K. In Windows the page size is also 4K, but aligned to a boundary of 64K (allocation granularity). Cygwin reconciles this by making the page size 64K. So in reality, Cygwin pages are 64K big, backed by 4K pages allocated along 64K boundaries.

When PHP reads a file, it looks at the file size. If there are enough bytes to read ahead in the last memory page after the EOF, PHP will use mmap. Else it will open the file normally.

When PHP is given a 4K file on Cygwin, it sees that the file and the bytes for reading ahead will easily fit into a 64K page (in Cygwin). So it mmap()s the file. However only one 4K page (in Windows) is mapped to. The remaining 60K pages are not. When PHP reads ahead past the EOF, it reads into page which has not been mapped to. This results in a segfault.

Changing the REAL_PAGE_SIZE to 4096 fixes the issue.

This bug is not a duplicate of any other bug as it is to do solely with the way Cygwin handles memory paging.

This definition needs to be fixed in two places as there are two different places where a PHP source file can be mmap()ed, depending on whether it is loaded using php-cli or loaded when php is run from a library. Please see the patch that I will attach.