Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I can't reproduce this with a CVS version, can you provide the backtrace.

httpd.exe - Apache 2.2.4.0 on Windows XP.

Thread 250 - System ID 39948
Entry point   msvcrt!_endthreadex+3a 
Create time   10.02.2009 18:35:47 
Time spent in user mode   0 Days 0:0:0.62 
Time spent in kernel mode   0 Days 0:0:0.15 

Function     Arg 1     Arg 2     Arg 3   Source 
ntdll!_SEH_prolog+1a     00270000     00000000     00000090    
msvcrt!_heap_alloc+e0     00000090     05c43098     77c1c42e    
msvcrt!_nh_malloc+13     00000090     00000000     06a524c7    
msvcrt!malloc+27     00000090     05c4323c     00000319    
php5ts!php_pcre_exec+5ad4     00000319     06a524c7     00000018    
0x05c4323c     06a524c7     00000018     00000000    

NTDLL!_SEH_PROLOG+1AIn httpd__PID__39128__Date__02_10_2009__Time_06_36_38PM__718__Second_Chance_Exception_C00000FD.dmp the assembly instruction at ntdll!_SEH_prolog+1a in C:\WINDOWS.0\system32\ntdll.dll from ?????????? ?????????? has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x05c42e24 on thread 250

5.3.0beta2-dev

Try increasing the value of pcre.backtrack_limit directive.
http://docs.php.net/manual/en/pcre.configuration.php

It doesnot work with decreased pcre.backtrack_limit and crushes with increased. What should I do?
Should me rewrite my compiler without pcre? :)

Scott, I got this:

==17735== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 71 from 1)
==17735== malloc/free: in use at exit: 16,528 bytes in 2 blocks.
==17735== malloc/free: 28,132 allocs, 28,130 frees, 3,660,888 bytes allocated.
==17735== For counts of detected errors, rerun with: -v
==17735== searching for pointers to 2 not-freed blocks.
==17735== checked 772,948 bytes.
==17735== 
==17735== 144 bytes in 1 blocks are definitely lost in loss record 1 of 2
==17735==    at 0x402401E: malloc (vg_replace_malloc.c:207)
==17735==    by 0x807C5A9: match (pcre_exec.c:1046)
==17735==    by 0x807C807: match (pcre_exec.c:1107)
==17735==    by 0x807BC10: match (pcre_exec.c:773)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BC10: match (pcre_exec.c:773)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735==    by 0x807CF5B: match (pcre_exec.c:1313)
==17735==    by 0x807BB9E: match (pcre_exec.c:765)
==17735== 
==17735== 
==17735== 16,384 bytes in 1 blocks are still reachable in loss record 2 of 2
==17735==    at 0x402401E: malloc (vg_replace_malloc.c:207)
==17735==    by 0x40D672C: (within /usr/lib/libfbclient.so.1.5.3)
==17735==    by 0x40D7718: (within /usr/lib/libfbclient.so.1.5.3)
==17735==    by 0x40D78BF: (within /usr/lib/libfbclient.so.1.5.3)
==17735==    by 0x40DA1F0: (within /usr/lib/libfbclient.so.1.5.3)
==17735==    by 0x40E6944: (within /usr/lib/libfbclient.so.1.5.3)
==17735==    by 0x4099030: (within /usr/lib/libfbclient.so.1.5.3)
==17735==    by 0x400DDE3: (within /lib/ld-2.7.so)
==17735==    by 0x400DF13: (within /lib/ld-2.7.so)
==17735==    by 0x400084E: (within /lib/ld-2.7.so)
==17735== 
==17735== LEAK SUMMARY:
==17735==    definitely lost: 144 bytes in 1 blocks.
==17735==      possibly lost: 0 bytes in 0 blocks.
==17735==    still reachable: 16,384 bytes in 1 blocks.
==17735==         suppressed: 0 bytes in 0 blocks.

As it isn't a PHP bug, I've reported it in http://bugs.exim.org/show_bug.cgi?id=809

Thanks.