Ich habe jetzt mal ziemlich viel gegoogled und habe mir auch den PHP Source angeschaut. Insgesamt halte ich das Szenario für einen Bug - nur kann ich nicht ohne weiteres sagen, ob es PHP Bug ist oder ein Third Party Bug.
Fakt ist, dieser Fehler taucht so erst seit PHP 5.2.x auf (manche Anwender haben in ihrer Verzweiflung auf 5.1.6 downgegraded).
Bei vielen Anwendern tritt das Problem im Umfeld von Third Party Produkten auf, beispielsweise WordPress oder irgendwelche Shopsysteme.
Im PHP Sourcecode wird mit dieser Fehlermeldung auf zwei unterschiedliche Fehlerursachen reagiert (leider - sonst könnte man den Fehler noch genauer eingrenzen):
a) zum Ausführen des compilierten Codes verwaltet PHP die notwendige Memory selbst in einem sog. "Heap" (= "Haufen"). Dieser Heap wird zur Laufzeit fragmentiert (weil bröckchenweise Speicher angefordert wird und wieder freigeben wird). Wenn die Verwaltung dieses Heaps "zerschossen" wird (eigentich ein Horrorfehler - irgendein Pointer steht dann quer, oder irgendeine Bibliothek, vielleicht auch PHP selbst, hat irgendwo einen Overflow), dann erfolgt o.g. Fehlermeldung.
b) die Fehlermeldung erfolgt auch, wenn im Heap kein ausreichend großes freies Stück mehr gefunden wird
und (und das ist der Knackpunkt) wenn ein alloc() (abhängig von Betriebssystem) "in die Hose geht".
Ich persönlich glaube aber, dass der Fall a) der häufigere ist, der Fall b) tritt eigentlich nur ein (oder sollte nur eintreten), wenn das OS wirklich nichts mehr anzubieten hat.
Es gibt einen einzigen Workaround, der bei vielen Anwendern geholfen hat - nämlich die Erhöhung des memory_limits, aber nicht nur in php.ini, sondern noch einmal explizit via ini_set() im betroffenen Script (oder in der index.php, falls das darüber liegt und das Script includiert wird). Also einfach in die erste Zeile schreiben:
- Code: Select all
<?php
ini_set('memory_limit', '128M');
...
Ich vermute, dass das nur deswegen hilft, weil der heap dann so groß ist, dass der Overflow (der natürlich immer noch passiert) nicht mehr die gleiche Wirkung zeigt. Wieso das expizite Setzen via ini_set() Erfolg hat, im Gegensatz zur alleinigen Erhöhung in php.ini, kann ich nicht erkennen, dazu müßte ich tiefer in den PHP Source einsteigen. Ich kann nur raten, dass ggf. diese Anweisung eine Neuformatierung (vielleicht auch Defragmentierung) des Heaps zur Folge hat (o.ä.). Ich weiß es nicht - aber probieren geht über studieren.
in Anbetracht dessen, dass dieser Fehler seit PHP 5.2 recht häufig auftritt, liegt der Verdacht nahe, dass etwas mit der Speicherverwaltung in PHP nicht stimmt. Was ich nicht erkennen kann, ob dieser Fehler spezifisch unter Windows öfter auftritt als unter Linux (oder ob er nur unter Windows auftritt?) - auch das wäre sicherlich einen Versuch wert, die ganze Umgebung auf Linux zu portieren.