Probleme mit rekursiven Patterns in PHP

[MarkusW]

hallo!

hab grad ein update von meinem lokalen server gemacht. es läuft jetzt Apache 2.2.2 und PHP 5.1.4 (also das neue xampp lite)

davor liefen Apache 2.0.51 [CAN-2004-0811.patch] und PHP 5.0.2

ich hatte einige preg_replace_callback funktionen mit rekursiven patterns die auch alle funktioniert haben. wenn ich die funktionen jetzt aufrufe stürzt der apache plötzlich ab (unknown software exception). (arbeite übrigens mit win2000)

weiß jemand woran das liegen könnte?

[Wiedmann]

Hast du ein (kurzes!) Beispiel um das mal nachzuvollziehen?

[MarkusW]

ja hab ich:

Code: Select all

   function parse($template) {
      $pattern = '/<tpl_[^\/]*?>(?:(?R)|(?(?=<tpl_[^\/]*?>).*?<\/tpl_.*?>|.*?))*?<\/tpl_.*?>/is';
      $template = preg_replace_callback($pattern, array(&$this, 'replace_block'), $template);

      $pattern = '/\{((?:(?R)|(?(?=\{).*?\}|.*?))*?)\}/';
      $template = preg_replace_callback($pattern, array(&$this, 'replace_brackets'), $template);
      
      $template = preg_replace('/\s(\s+)/s', '$1', $template);
      return $template;
   }

sobald diese funktion aufgerufen wird gibt der apache ne (windows)fehlermeldung.
ich hab das ganze soweit eingegrenzt das er wirklich bei dieser zeile abbricht:
$pattern = '/<tpl_[^\/]*?>(?:(?R)|(?(?=<tpl_[^\/]*?>).*?<\/tpl_.*?>|.*?))*?<\/tpl_.*?>/is';
$template = preg_replace_callback($pattern, array(&$this, 'replace_block'), $template);

also sobald ich ein pattern mit (?R) aufrufe.

[MarkusW]

hab übrigens grad nochmal den alten apache gestartet und da gehts nach wie vor.

edit:

jetzt hab ich grad nochmal was probiert:

Code: Select all

$pattern = '/<tpl_[^\/]*?>(?:(?R)|(?(?=<tpl_[^\/]*?>).*?<\/tpl_.*?>|.*?))*?<\/tpl_.*?>/is';
echo preg_replace($pattern, 'works', $text);


funktioniert für

Code: Select all

$text = <<< END
<tpl_if isset="admin">
<a href="{login}" class="admin">Logout</a>
<tpl_else />
<a href="{login}" class="admin">Login</a>
</tpl_if>
END;


und funktioniert nicht für

Code: Select all

$text = <<< ENDE
<tpl_if isset="admin">
function deletegallery() {
   return confirm('Galerie mit allen Bildern und Kommentaren wirklich löschen?');
}
function deleteimage() {
   return confirm('Bild mit allen Kommentaren wirklich löschen?');
}
</tpl_if>

<tpl_if isset="admin">
<a href="{login}" class="admin">Logout</a>
<tpl_else />
<a href="{login}" class="admin">Login</a>
</tpl_if>
ENDE;


[Wiedmann]

Code: Select all

$pattern = '/<tpl_[^\/]*?>(?:(?R)|(?(?=<tpl_[^\/]*?>).*?<\/tpl_.*?>|.*?))*?<\/tpl_.*?>/is';

Also eingesetzt in ein simples preg_replace() macht das keine Probleme. Das Test-Template war aber auch nur ein kurzer Satz der nicht mal matchte...

Mehr kann ich da nicht wirklich testen, da mir ja schon dein Object und die Methode vom Callback fehlt.

Hab aber leider grad so keine Idee was wirklich ist. (Evtl. liegts ja auch am callback/referenz zu diesem Object).

Der eAccelerator oder Zend Optimizer könnte da auch Probleme machen, falls aktiv.

[MarkusW]

Mehr kann ich da nicht wirklich testen, da mir ja schon dein Object und die Methode vom Callback fehlt.

Hab aber leider grad so keine Idee was wirklich ist. (Evtl. liegts ja auch am callback/referenz zu diesem Object).

Der eAccelerator oder Zend Optimizer könnte da auch Probleme machen, falls aktiv.

also an dem objekt liegts nicht da dieser code auch abschmiert:

Code: Select all

<?php

$text = <<< ENDE
<tpl_if isset="admin">
function deletegallery() {
   return confirm('Galerie mit allen Bildern und Kommentaren wirklich löschen?');
}
function deleteimage() {
   return confirm('Bild mit allen Kommentaren wirklich löschen?');
}
</tpl_if>

<tpl_if isset="admin">
<a href="{login}" class="admin">Logout</a>
<tpl_else />
<a href="{login}" class="admin">Login</a>
</tpl_if>
ENDE;

$pattern = '/<tpl_[^\/]*?>(?:(?R)|(?(?=<tpl_[^\/]*?>).*?<\/tpl_.*?>|.*?))*?<\/tpl_.*?>/is';
echo preg_replace($pattern, 'works', $text);
 
?>

das is die komplette testdatei die den fehler verursacht.

wie kann ich denn die anderen sachen abschalten?

[Wiedmann]

also an dem objekt liegts nicht da dieser code auch abschmiert:

Stimmt, da crashed es dann... Nur mit den ersten 5. Zeilen in $text tut's hier noch. Ab der 6. dann nicht mehr.
Interessanterweise tut's in der Konsole korrekt. Nur im Apache-Modul nicht. Da läuft wohl irgendwas über.

wie kann ich denn die anderen sachen abschalten?

Das macht hier zwar nichts aus, aber das macht man in der "php.ini".

[MarkusW]

Stimmt, da crashed es dann... Nur mit den ersten 5. Zeilen in $text tut's hier noch. Ab der 6. dann nicht mehr.
Interessanterweise tut's in der Konsole korrekt. Nur im Apache-Modul nicht. Da läuft wohl irgendwas über.

also zu deutsch: es liegt am apache und da kann man nichts machen? ich geb zu das das pattern ziemlich brutal is und recht langsam aber sooo schlimm das was überlauft isses eigendlich nicht... schade!

und wieso eigendlich in der 6. zeile?! da is eigendlich garnichts was mit dem pattern zu tun hat...

[Wiedmann]

also zu deutsch: es liegt am apache

Möglich. Jedenfalls passiert es nur unter Windows und nicht unter *nix...

aber sooo schlimm das was überlauft isses eigendlich nicht... schade!
und wieso eigendlich in der 6. zeile?! da is eigendlich garnichts was mit dem pattern zu tun hat...

Was bei Recursionen "schnell" passieren könnte. Siehe auch die PCRE-Doku:

This means that the available stack space may limit
the size of a subject string that can be processed by certain patterns.
For a discussion of stack issues, see the pcrestack documentation.

und die PHP-Doku:

This extension maintains a global per-thread cache of compiled regular expressions (up to 4096).

Und jetzt weis man ja, dass der Apache unter WIndows immer threaded ist (was OOS-software oft nicht richtig beherrscht :-/), im Gegensatz zu unter *nix.

Wer da von denen 2 jetzt was falsch macht, weis ich nicht. So wie ich die jeweiligen Bugsysteme kenne, werden die sich die Schuld wieder gegenseitig zuschieben *g*


Evtl. Kannst du ja die Pattern ändern...

[MarkusW]

Evtl. Kannst du ja die Pattern ändern...

bleibt mir wohl nix anderes übrig. schade eigendlich. in dem pattern stecken 2 stunden arbeit

danke für die hilfe!