Wyrazenie regularne zabija proces httpd.exe

Mam taki skrypt:

<?php

$string = '< PASS_COUNT; i++) { if (strcmp(password, PASSWD2) == 0) continue;	 } c++; if (c == 3) break; }	 // Tu wlasciwe sprawdzanie hasla }dku gdy liczy sie wydajnosc, gdyz petle zabieraja niestety troche czasu :( ale jest to niewiele i w sumie to nie czuc roznicy. Kolejna sprawa jest sposob porownywania hasla. NIGDY nie dokonuj deszyfracji klucza w programie (mam nadzieje ze chociaz szyfrujesz klucze :)). Jest to pierwsza i najwazniejsza zasada ! Wiec jak sprawdzic czy wprowadzony klucz jest poprawny. Zaszyfruj go i porownaj zaszyfrowane klucze. Ktos kto sledzi Twoj program ma wtedy utrudnione zadanie, a gdy poprawny klucz jest deszyfrowany to ktos sobie przejdzie do momentu az klucz bedzie zdeszyforwany i tylko go spisze. Od metody szyfracji zalezy bezpieczenstwo Twojego programu wiec staraj sie dobierac algorytm, ktory dobrze szyfruje (nie mowie tu o Triple-DES itp. ;) ). Marzeniem bylby algorytm jednostronny, ktorego odszyfrowania jest trudniejsze niz brute-force ale na to nie licz. Najlepiej ';
preg_match('~(</?)(\w*)((/(?!>)|[^/>])*)(/?>)~', $string, $matches);

?>

Proba uruchomienia konczy sie tym, ze PHP wywala caly proces Apache (Windows 7, na PHP 5.3.10). Czy u Was tez jest tak samo?

XP, php 5.2.12
Nie wywala procesu apache, ale zamula, sporo rośnie zużycie pamięci (ok 64 MB było na domyślnym limicie czasu). Ostatecznie chyba zamyka połączenie bez zwrotu nawet nagłówków, bo Opera wywala: "Połączenie przerwane przez serwer".

[win xp, apache 2.2.17, php 5.3.5]

Oczywiście wywala się, ale taki skrypcik bez problemu chodzi odpalany w stylu php test.php - wykonuje się, $matches jest pustą tablicą itp. :/

Na IIS 7.5 przy PHP jako FastCGI działa. Wniosek? FCGI jest lepsze od modułu :-)

Ok, dzieki za informacje. Czyli jest to jakis bug PHP.

Jeden z wielu, cóż, random <strike>bugs</strike> features :P

Zabójczy regex. Chciałem wkleić wynik testu do posta, przywiesiło Firefoksa. Wkleiłem do pastebina, w efekcie: "Program wykonał nieprawidłową operację."

Generalnie: 6117 kroków by ten regex zwrócił fail. Idzie co literkę i potem robi backtrack. Zabójstwo dla parsera. Nie dziwi mnie, że się wywala.

[edit]
dla przykładowego ciągu: < cokolwiek tutaj mamy 107 kroków - ogromna ilość:

<
<
<backtrack
< 
< backtrack
< c
< cbacktrack
< co
< cobacktrack
< cok
< cokbacktrack
< coko
< cokobacktrack
< cokol
< cokolbacktrack
< cokolw
< cokolwbacktrack
< cokolwi
< cokolwibacktrack
< cokolwie
< cokolwiebacktrack
< cokolwiek
< cokolwiekbacktrack
< cokolwiek 
< cokolwiek backtrack
< cokolwiek t
< cokolwiek tbacktrack
< cokolwiek tu
< cokolwiek tubacktrack
< cokolwiek tut
< cokolwiek tutbacktrack
< cokolwiek tuta
< cokolwiek tutabacktrack
< cokolwiek tutaj
< cokolwiek tutajbacktrack
< cokolwiek tutajbacktrack
< cokolwiek tutaj
< cokolwiek tutaj
< cokolwiek tutajbacktrack
< cokolwiek tutajbacktrack
< cokolwiek tuta
< cokolwiek tuta
< cokolwiek tutabacktrack
< cokolwiek tutabacktrack
< cokolwiek tut
< cokolwiek tut
< cokolwiek tutbacktrack
< cokolwiek tutbacktrack
< cokolwiek tu
< cokolwiek tu
< cokolwiek tubacktrack
< cokolwiek tubacktrack
< cokolwiek t
< cokolwiek t
< cokolwiek tbacktrack
< cokolwiek tbacktrack
< cokolwiek 
< cokolwiek 
< cokolwiek backtrack
< cokolwiek backtrack
< cokolwiek
< cokolwiek
< cokolwiekbacktrack
< cokolwiekbacktrack
< cokolwie
< cokolwie
< cokolwiebacktrack
< cokolwiebacktrack
< cokolwi
< cokolwi
< cokolwibacktrack
< cokolwibacktrack
< cokolw
< cokolw
< cokolwbacktrack
< cokolwbacktrack
< cokol
< cokol
< cokolbacktrack
< cokolbacktrack
< coko
< coko
< cokobacktrack
< cokobacktrack
< cok
< cok
< cokbacktrack
< cokbacktrack
< co
< co
< cobacktrack
< cobacktrack
< c
< c
< cbacktrack
< cbacktrack
< 
< 
< backtrack
< backtrack
<backtrack
<backtrack
<backtrack
<backtrack
<backtrack
backtrack
Match attempt failed

Wszelka pomoc mile widziana :) Ten regexp jest wykorzystywany tutaj: http://redmine.boduch.net/projects/coyote/repository/entry/trunk/lib/filter/html.class.php w filtrze znacznikow HTML.

Nie będzie prościej napisać/wykorzystać jakiś tokenizer zamiast dumać nad kilometrowym regexem? Tam niżej widzę kolejne rarytasy.
Coś w stylu http://htmlpurifier.org/ (nie wiem czy obsługuje własne tagi, np. <url)

Purifier dopuszcza biala lite, ale to jest straszna kobyla i malo wydajna. Ta klasa, ktora podalem w poprzednim linku jest wykorzystywana (z drobnymi modyfikacjami) w Zendzie, gdyby tylko nie wywalala serwera ;)) Ludzie od PHP nie moga zidentyfikowac bledu (SOA#1) wiec musze dostarczyc im szerszego debuga.

Obstawiam ustawienia pamięci dla PHP.

<1 | 25
<12 | 45
<123 | 71
<1234 | 103
<12345 | 141
<123456 | 185
<1234567 | 235
<12345678 | 291
<123456789 | 353
<1234567890 | 421

Więc jak widać, w drugim przypadku złożoność obliczeniowa rośnie mniej więcej wykładniczo

Dostalem odpowiedz:

It is not something PHP is responsible for. The stacksize of Apache is too
small, it works in PHP's cli because PHP builds have a larger default stacksize.

You can increase it using this config option:

http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ThreadStackSize

or change the default stacksize of the Apache binaries:

http://msdn.microsoft.com/en-us/library/xd3shwhf.aspx

Czyli dokładnie to co napisałem w poprzednim poście i poparłem wykresem.
Serio, pomyślałbym raczej o jakimś tokenizerze (co za paskudny wyraz) niźli takim ciężkim wyrażeniu.