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

Ok, I am going to post the results within a few minutes

I have tested with the current v4.4.7 and there is the same problem; I have seen the same bug marked as "bogus" for other OSes since looks like being a PCRE library bug.

I have clues that this bug breaks A LOT of different PHP applications

It's a stack overflow in the pcre library... so how can we fix this?

Would it be viable to compile with an older PCRE library?

And, is the PCRE development team addressing the issue of their most recent release?

I've no idea if they are looking at this. And no, compiling with an older lib is not possible as the new version has plenty of bug fixes as well.

http://sourceforge.net/tracker/index.php?func=detail&aid=1688293&group_id=10194&atid=360194
exists though.

I understand.

I will try to contact the PCRE mantainer, and if he is not working on the issue I will try to get my hands dirt and patch it myself. If I end up with a patch for the PCRE library I hope it will be accepted in PHP's  CVS tree

If the bug is not reproducible out of PHP (with a C testcase, for example) there are high chances that it is a PHP-related bug.

I will now test the bug out of PHP and see if it still happens.

I have tested the subject and regex in a C snippet and the segmentation fault does not happen

So the bug is someway related to PHP's usage (maybe initialization and reset?) of the PCRE library

More tests would be needed, of course

We can't fix PCRE.

Of course.

But did you check if the bug(s) also happens out of PHP? e.g. if it is ONLY a PCRE bug?

I found a workaround for my own problem, maybe it will help other users or help individuating the bug.

<?php
// by legolas558

$regex = "(?i:begin|start)\\s+([^']*('[^']*')*)*";

$old_php_regex = "/".$regex."/";

// notice the greedy/ungreedy change which actually works around the segmentation fault
$bug41050_regex = "/".$regex."?/";

// test case
$subject = "begin\nnon string 'string' other non string";

// will work on any PHP - also the latest versions with PCRE7
preg_match_all($bug41050_regex, $subject, $m);

echo '<pre>';var_dump($m);echo '</pre>'; unset($m);

// will cause a segmentation fault (and so a 500 server error) if used on PHP versions compiled with PCRE7
// preg_match_all($old_php_regex, $subject, $m);

echo '<pre>';var_dump($m);echo '</pre>';

?>

G.Baconniere kindly provided a patch to downgrade PHP 4.4.6's internal PCRE7 to PCRE6.6

http://www.infomaniak.ch/php4/php-4.4.6-downgrade_pcre.patch

I have not tested it, however the author is trusted.

Note: use at your own risk, you will not take advantage of the bugfixes in PCRE7

You don't have to apply any patches in order to build PHP with external PCRE (if you don't like the bundled version).
Use --with-pcre-regex=DIR option to do that.