|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65312 Segmentation fault with filesize=4096
Submitted: 2013-07-23 00:00 UTC Modified: 2013-07-24 10:14 UTC
From: bee8192 at gmail dot com Assigned:
Status: Duplicate Package: *General Issues
PHP Version: 5.5.1 OS: Win7x64+Cygwin
Private report: No CVE-ID: None
 [2013-07-23 00:00 UTC] bee8192 at gmail dot com
php fails to parse any file with size 4096 with "Segmentation fault (core dumped)" 
message on Cygwin. Adding or deleting any character from the file fixes the 

Test script:
/home/Eugene/test>php -r 'echo str_repeat("\n", 4096);' > test.php
/home/Eugene/test>ls -l
total 4
-rw-r--r--+ 1 Eugene 4096 Jul 23 00:42 test.php
/home/Eugene/test>php -f test.php
Segmentation fault (core dumped)

Expected result:
4096 new lines.

Actual result:
Segmentation fault (core dumped)


cygwin-mmap-pagesize-patch (last revision 2017-05-05 16:56 UTC by ricardohenrylee at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-23 06:23 UTC]
-Status: Open +Status: Feedback
 [2013-07-23 06:23 UTC]
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 for *NIX and 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 
 [2013-07-23 21:23 UTC] bee8192 at gmail dot com
-Status: Feedback +Status: Open
 [2013-07-23 21:23 UTC] bee8192 at gmail dot com
(gdb) bt
#0  lex_scan (zendlval=zendlval@entry=0x285888) at 
#1  0x006e840f in zendlex (zendlval=zendlval@entry=0x285880) at /install/php-
#2  0x006c2f0e in zendparse () at /install/php-
#3  0x006c98f2 in compile_file (file_handle=0x289944, type=8) at 
#4  0x005a0c72 in phar_compile_file (file_handle=0x289944, type=8) at 
#5  0x006fe22d in zend_execute_scripts (type=type@entry=8, 
retval=retval@entry=0x0, file_count=file_count@entry=3) at /install/php-
#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-
#8  0x007b1e6c in main (argc=2, argv=0x28ac1c) at /install/php-

One would rather need php in cygwin environment than need cygwin to run php.
 [2013-07-24 07:25 UTC]
-Status: Open +Status: Feedback
 [2013-07-24 07:25 UTC]
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.
 [2013-07-24 09:16 UTC]
Hi again. Could you please also post the ./configure arguments?
 [2013-07-24 09:51 UTC]
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
 [2013-07-24 10:14 UTC]
-Status: Feedback +Status: Duplicate
 [2013-07-24 10:14 UTC]
see bug #52752
 [2015-10-26 21:42 UTC] sabel at altmuehlnet dot de
This also occurs with a file size of 8192 bytes!
 [2017-05-05 16:54 UTC] ricardohenrylee at gmail dot com
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.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 14 18:01:29 2024 UTC