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? 

I compiled CVS 200702251930 but unfortunately the problem persists.

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.

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.

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.

also please post the whole backtrace, so that we can see what's happening (it may be just a stack overflow..)

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

Yup, it does look like a stack overflow (which is a known issue in PCRE), though we would appreciate a test case anyway.

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.

>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.

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.

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".

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.

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)

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