|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60976 PHP crashes sometimes while parsing
Submitted: 2012-02-03 23:39 UTC Modified: 2020-03-05 09:58 UTC
Avg. Score:4.2 ± 1.0
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:2 (50.0%)
From: xrstf-misc at yahoo dot com Assigned: cmb (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.3.10 OS: Win7x64
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: xrstf-misc at yahoo dot com
New email:
PHP Version: OS:


 [2012-02-03 23:39 UTC] xrstf-misc at yahoo dot com
I know this is not really helpful, but that's the best I can describe it. Sorry 
that I cannot give a short, minimal test script to reproduce the bug.

Sometimes, when coding, I change one single line of code (i.e. change a string 
literal) and when re-running the script in my browser, Apache/PHP crashes. In 
this case, the affected line was

$params['subject'][] = array('metainfo', 'Metainfos');

I changed the line to

$params['subject'][] = array('metainfo', t('metainfos'));

which suddenly crashes PHP. When I change the argument of t() to 'metainfo' or 
'metainfoX' or 'metainfosX', PHP does not crash. If I change the value back to 
'metainfos', it crashes. Every newly spaned apache worker also crashes. If I 
move the line just down one line, PHP does not crash. Sounds like a parser bug 
in combination with APC (see below)


  PHP 5.3.10 TS
  Win7 x64
  Apache 2.2.17 (PHP module)

VS2008 shows me the following backtrace:

Let me know if you need more details.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-03 23:41 UTC] xrstf-misc at yahoo dot com
Oh, there is a false statement still left in the original report: The crash also 
happens *without* APC (or any other opcode cache).
 [2012-02-04 00:43 UTC]
-Status: Open +Status: Feedback
 [2012-02-04 00:43 UTC]
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.

 [2012-02-04 01:20 UTC] xrstf-misc at yahoo dot com
-Status: Feedback +Status: Open
 [2012-02-04 01:20 UTC] xrstf-misc at yahoo dot com
Well this is the source file that caused the parse error: (md5sum is 
1bd8de828db862a5f118be4cc9773999, there are not trailing spaces and there is a 
blank line at the end of the file).

I cannot give any shorter example. Sorry.
 [2012-02-04 07:37 UTC]
Please provide us the full script you use to reprodruce the crash.
 [2012-02-04 07:37 UTC]
-Status: Open +Status: Feedback
 [2012-02-04 07:39 UTC]
Ah you already did. Which EOL do you use on your original script? Unix or windows 

Maybe zip it and post a link to the zip file, so the contents won't be altered 
(lexer bug).
 [2012-02-05 15:19 UTC] xrstf-misc at yahoo dot com
-Status: Feedback +Status: Open
 [2012-02-05 15:19 UTC] xrstf-misc at yahoo dot com
Here is the original file, wrapped in an 7z archive: (1KB)
 [2012-02-06 17:23 UTC] giunta dot gaetano at gmail dot com
I also have php crashes - win7 64, apache 2.2.21 from apache lounge.
No error messages left in either php or apache logs - just a "server reset connection" error from the browser.
The code ran fine up to php 5.3.8 (did not test with 539).
It involves executing a custom page within eZPublish, it is hard for me to trace it to a single php file / command and attach it here...
 [2012-02-09 13:59 UTC] hanssen at aeteurope dot nl
I experience an issue which I think is caused by the same bug (PHP crashes in line 3182 of Zend/zend_language_scanner.c (contains "if ((yych = *YYCURSOR) == '\n') goto yy203;", part of function lex_scan()).

In my case I call php_strip_whitespace() on a PHP file with a length of exactly 4096 bytes (the same length as the problem file reported by the original author of this bug) and where the file ends with "?>" without trailing newline.

Inspection of lines 3181 and 3182 of Zend/zend_language_scanner.c reveals YYCURSOR being advanced one byte and a '\n' being expected, which fails here because it attempts to read memory beyond allocated memory.
 [2012-02-10 01:50 UTC] xrstf-misc at yahoo dot com
This is actually a good hint by hanssen at aeteurope dot nl: I too had some cases 
where a generated cache file (containing "<?php $data = var_export(...)") would 
crash PHP when it was exactly 4096 Byte in size.
 [2012-03-13 19:42 UTC] pete dot walker at cap2 dot co dot uk
I'm also suffering from this issue. I had phpunit randomly crashing. Traced the 
problem using xdebug - I'm using the Database YAML extension 
(PHPUnit_Extensions_Database_DataSet_YamlDataSet), and it uses the include 
statement to load the YAML files.

The YAML file knocking everything over was exactly 8192 bytes long (and ended 
with whitespace, but not \n).
 [2013-06-05 12:11 UTC] arjen at react dot com
Bug is about 8192 bytes long scripts.
 [2020-03-05 09:58 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2020-03-05 09:58 UTC]
I cannot reproduce this crash (using Metainfo.php from
bug60976.7z) with any of the actively supported PHP versions[1],
so I assume this issue has been resolved in the meantime.

[1] <>
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Nov 25 06:01:23 2020 UTC