php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #40624 pcrelib broken with php 4.4.5
Submitted: 2007-02-25 03:04 UTC Modified: 2007-03-08 01:00 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:0 (0.0%)
From: test_junk at hotmail dot it Assigned:
Status: No Feedback Package: PCRE related
PHP Version: 4.4.5 OS: linux 2.4 i386
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: test_junk at hotmail dot it
New email:
PHP Version: OS:

 

 [2007-02-25 03:04 UTC] test_junk at hotmail dot it
Description:
------------
Recent update to php 4.4.5 broke PCRE regex support.
The issue showed up upgrading to 4.4.5 installed as apache module (1.3.37 both on 2.4 and 2.6 kernels) and was resolved downgrading back to 4.4.4

I could trigger a segfault with several applications but I was not able to detect the chunk of php code responsible of it.

Actual result:
--------------
segfault...

#0  match (eptr=0x0, ecode=0x0, offset_top=0, md=0x0, ims=0, eptrb=0x0, flags=0, rdepth=0)
    at /sources/php-4.4.5/ext/pcre/pcrelib/pcre_exec.c:517
Cannot access memory at address 0xbf7fff30   

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-02-25 18:06 UTC] derick@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

PCRE was upgraded again in 4.4.6rc1, could you please try that? 
 [2007-02-25 22:14 UTC] test_junk at hotmail dot it
I compiled CVS 200702251930 but unfortunately the problem persists.
 [2007-02-25 23:03 UTC] nlopess@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

sorry, can you please try again a new snapshot? I made some changes a few hours ago and I don't know if they made their way in the snapshot you tested.
If it still doesn't work, please post the entire backtrace (or link to an external page if it's too big). Also please try to isolate the code that triggers the bug.
 [2007-02-26 00:24 UTC] test_junk at hotmail dot it
This snapshot is identical to the one I tested as far as I am seeing comparing the 2 archives, however which files did you modify?

The only way I have to trigger this bug is recompiling the engine on a production server but since it breaks several websites (Drupal seems to be most affected) I can do it only at night so I can perform a limited number of attempts.
 [2007-02-26 08:58 UTC] tony2001@php.net
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.


 [2007-02-26 14:00 UTC] nlopess@php.net
also please post the whole backtrace, so that we can see what's happening (it may be just a stack overflow..)
 [2007-02-27 23:39 UTC] test_junk at hotmail dot it
I couldn't isolate the code yet. However the full backtrace is the following (I ran the same app twice):

1st time:

#0  0x081851f2 in match (eptr=0x61737361 <Address 0x61737361 out of bounds>,
    ecode=0x2c69746c <Address 0x2c69746c out of bounds>, offset_top=1919250464, md=0x7474656d,
    ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160)
    at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:2209
#1  0x00000000 in ?? () 


2nd time:

#0  0x0818257f in match (eptr=0x61737361 <Address 0x61737361 out of bounds>,
    ecode=0x2c69746c <Address 0x2c69746c out of bounds>, offset_top=1919250464, md=0x7474656d,
    ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160)
    at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:1071
Cannot access memory at address 0xbf7ffff0
 [2007-02-28 00:13 UTC] tony2001@php.net
Yup, it does look like a stack overflow (which is a known issue in PCRE), though we would appreciate a test case anyway.
 [2007-02-28 07:07 UTC] test_junk at hotmail dot it
Is this issue going to be fixed in the next release? Unfortunately it breaks lots of things, including very popular apps. I will try to do my best in finding the responsible php code but I'm not sure it will be possibile.
Thanks for your interest in this matter.
 [2007-02-28 08:01 UTC] tony2001@php.net
>Is this issue going to be fixed in the next release?
We got a workaround for it in PHP5, but we're not going to add it to PHP4, so you have to upgrade your PHP first.
This issue (if it's really what it seems to be) is actually not PHP problem, but a well-known PCRE issue.
Though, I wouldn't be 100% sure without a test-case.
 [2007-02-28 11:49 UTC] test_junk at hotmail dot it
I downgraded the PCRE lib to the 6.6 release, the one shipped with php 4.4.4 and the problem appears to be resolved.
It's indeed a PCRE issue, I hope they will fix it in the future releases.
 [2007-03-08 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2007-04-04 20:44 UTC] ted_johnson2 at yahoo dot com
Using the latest versions of apache2.2 and php (both installed via the debian etch repository; also trying the CVS snapshot of php for 4/4/2007) this is still an issue.

Furthermore, the php.ini directives do nothing. I can set them to 1, 10, 100, or any value I choose and not see a positive change in the test case.  The failure is still 100% reproducible.
 [2007-05-13 16:01 UTC] tom dot myny at tigron dot be
Hello,

I have the same problem with PHP 4.4.7


[Thread debugging using libthread_db enabled]
[New Thread -1218357568 (LWP 2423)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218357568 (LWP 2423)]
match (
    eptr=0x89ea7f8 "Ingredi?nten<p> een kloeke braadkip, ca. 2 Kg, bv. eentje uit de Landes<p> 4 sjalotten<p> 100 g chocolade, extra donkere bv. Cote&nbsp;(...)", ecode=0x897ed4a "Y", offset_top=4, md=0xbfdc2a10, ims=0, eptrb=0x0,
    flags=0, rdepth=5704)
    at /usr/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c:517
517     prop_value = 0;
(gdb) quit


This wasn't with 4.4.4 but i have also updated my distribution to the latest debian stable version (etch)
 [2007-05-13 16:04 UTC] tom dot myny at tigron dot be
I have this with the latest 5.5.2:

[Switching to Thread -1216501536 (LWP 2903)]
0x080b11b4 in match (eptr=<value optimized out>, ecode=<value optimized out>,
    offset_top=<value optimized out>, md=0xbfb4329c, ims=0, eptrb=0x0,
    flags=0, rdepth=11068)
    at /usr/src/php-5.2.2/ext/pcre/pcrelib/pcre_exec.c:629
629             RMATCH(rrc, eptr, ecode + _pcre_OP_lengths[*ecode], offset_top, md,

Regards,
Tom
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 09:01:28 2024 UTC