Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64397
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
To: internals@lists.php.net
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Jani Ollikainen <jani.ollikainen@mmd.net>
Date: Fri, 21 Dec 2012 07:15:22 +0100
Message-ID: <5952719.MaJMSR3yMW@rofl>
User-Agent: KMail/4.9.4 (Linux/3.6.11-k10-bof; KDE/4.9.4; x86_64; ; )
In-Reply-To: <50D35BA0.5010301@sugarcrm.com>
References: <50D1D9B9.4060505@mmd.net> <50D30656.8090207@mmd.net> <50D35BA0.5010301@sugarcrm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [PHP-DEV] Crashes in lex_scan at  Zend/zend_language_scanner.c / BUG #52752
From: php@bof.de (Patrick Schaaf)

On Thursday 20 December 2012 10:40:32 Stas Malyshev wrote:
> Hi!
> 
> > <?php
> > if ($argv[1] > 0) {
> > 
> >    while ($argv[1]--) file_put_contents('test.tpl', "<?php
> > 
> > #".str_repeat('A', mt_rand(4000, 5000))." ?>\n", LOCK_EX);
> > } else {
> > 
> >    $p2 = popen("sapi/cli/php -n test3.php 100", "r");
> >    while (1) include 'test.tpl';
> > 
> > }
> > ?>
> 
> Yes, I can now reproduce this on my machine too. Not sure what I did
> wrong last time, but now I get bus error. I suspect there's some race
> condition between mmap and rewriting the file that creates the problem.
> The error seems to happen at offset exactly 0x1000 from the start of the
> map, which leads me to thinking that maybe the problem is that the page
> needs to be loaded, but since the file is not there, being overwritten,
> it can not be loaded anymore.

Is include supposed to take a LOCK_EX somehow? I can neither see that in php-
src (5.4.9) nor APC-trunk, doing a cursory grepping.

 APC takes a LOCK_EX in exactly one place, apc_bin_dumpfile(), which does not 
look to me like it's related to "include". The usage there is fishy anyway, 
not exactly sure, but I think the open that happens before taking LOCK_EX, 
will have truncated the file already, leading to the same type of problem as 
discussed above wrt concurrent readers.

The only chance to get the above piece of code to work reliably in theory, 
would be for the "include" to take a LOCK_EX before looking at anything 
related to the file structure, including the stat call that determines how 
much to mmap.

The prudent approach, which should avoid the problem altogether and not need 
any LOCK_EX, dictates to ALWAYS write a temporary file (new inode), then 
rename it when the write completely succeeds. Otherwise any reader, like 
"include", runs the chance of seeing a partially written file, and even 
without include using mmap internally, syntax errors would happen from time to 
time.

So, my conclusion would be that it is the code snippet above, and not any part 
of PHP or the kernel, that is at fault.

best regards
  Patrick