[php] Bug in PHP 3.0.16 (?)

[Andreas Braukmann]

Hallo,

 ... ein Leidensgenosse, ... ein Leidensgenosse ...
 hurra, ... vielleicht kommen wir der Sache ja nun 
 auf die Spur.

On Fri, Apr 28, 2000 at 06:25:50PM +0200, Markus Dobel wrote:
> vor einiger Zeit hatte ich in der Newsgroup de.comp.lang.php von einem
... in der Newsgroup muss es mir entgangen sein, da ich sie
immer nur sehr fluechtig lese (mit hohem 'score' auf 'kk' ;) ).


> Fehlverhalten des PHP-Moduls auf meinem Rechner berichtet. Bis heute
> scheint jedoch keiner ausser mir hier diesen Fehler nachvollziehen zu
> koennen. 
Das Gefuehl kenn ich. Ich kann im Moment so wenig zu diesen
Symptomen sagen, dass ich mich bisher nichteinmal an die
Oeffentlichkeit der Mailingliste gewagt habe.


> Er fiel mir auf, als ich fuer die PHPlib das auto_prepend_file
> per .htaccess-Datei konfigurieren wollte.
Ich muss bei zweien unsere Apache-Installationen genau dasselbe 
Sympthom beobachten; konnte es bisher aber _nie_ auf eine bestimmte 
Ursache zurueckfuehren. 

> Daher dachte ich, es laege vielleicht wirklich an meiner speziellen
> Konfiguration bzw. einem Fehler meinerseits und 
Ich dachte bisher auch eher an eine Plattform-Inkompatibilitaet;
aber bis zu diesen merkwuerdigen Fehlern liefen die selbst-
gebauten Apache/PHP-Kombis bei uns 'rock-stable'.

Unsere Plattform bei den beiden betroffenen Installation
ist FreeBSD 2.2.8-stable.
Auf dem einen laeuft:
    Server Version: Apache/1.3.9 (Unix) PHP/3.0.13-dev
und auf dem anderen:
    Server Version: Apache/1.3.12 (Unix) PHP/3.0.17-dev


> habe mir anstatt der php3_auto_prepend_file-Geschichte mit einem
> require der PHPlib-prepend.php3 beholfen.
Insbesondere taucht es bei uns auch ganz ohne auto_prepend_file 
auf; allerdings setze ich php3_include-Pfade und diverse
php3-Optionen in .htaccess-Dateien.

> Nun hatte ich heute die Gelegenheit, auf einem voellig jungfraeulichen
> SuSE 6.3 noch einmal ein wenig damit herumtesten zu koennen, und siehe
> da, auch dort hatte ich wieder den gleichen Fehler.
... dann kann ich mir ausfuehrliche Tests unter FreeBSD 3.4-stable
und 4.0-stable und 5.0-current ja fast sparen; da das Problem
offensichtlich nicht an FreeBSD 2.2.x liegt.
Andererseits waere es natuerlich schon ganz interessant zu wissen,
ob das Problem unter 4.0-stable noch besteht.
Meine Vermutungen (fuer die ich ehrlich gesagt keine wirklich
fundierte Begruendung liefern koennte) gehen in Richtung eines
Speicherverwaltungsproblem in der Kombination apache/mod_php3.
Ich hab' die Absturz-Haeufigkeit deutlich senken koennen, in 
dem ich dem Apache ein "MaxRequestsPerChild 2" spendiert habe und
dafuer die 'MinSpareServers' erhoeht habe (um wenigstens einen
Teil des Performance-Verlustes wieder auszugleichen).


> nachzuvollziehen bzw. mir zu sagen, ob das nun ein Fehler ist, der bei
> mir liegt oder doch bei PHP. Bisher scheue ich mich noch, dafuer einen
> Bug-Report abzusetzen, da sonst scheinbar keiner diesen Fehler bisher
> provozieren konnte.
... ich bin mir nun ziemlich sicher, dass es ein Fehler in php 
oder apache ist. Ich finde es allerdings auch bemerkenswert, dass
ein Bug mit derartig frappanten Auswirkungen noch niemand anderem
aufgefallen sein sollte.
Er tritt (soweit wir es beurteilen koennen) auf einem
Server Version: Apache/1.3.0 (Unix) PHP/3.0 nicht auf.
Allerdings liegen zwischen diesem Releasestand und den weiter oben
genannten sowohl beim Apache als auch beim PHP Welten.

> Die Serversoftware dort ist nun:
Unser Server Version: Apache/1.3.12 (Unix) PHP/3.0.17-dev
ist so konfiguriert:

Fuer php3 (cvs-Version)
./configure --with-apache=/tse/sw-tse/www/apache \
                --with-mysql=/usr/local \
                --with-exec-dir=/wwwsrv/php-bin \
                --enable-track-vars \
                --enable-magic-quotes \
                --enable-bcmath \
                --enable-memory-limit \
                --with-config-file-path=/www/etc

Das ist schon extra eine absolute Schmalspur-Version, da ich
zunaechst Fehler in irgendwelchen Modulen komplett ausschliessen
wollte.


Fuer Apache:
./configure --prefix=/www \
        --enable-module=access \
        --enable-module=actions \
        --enable-module=alias \
        --enable-module=asis \
        --enable-module=auth \
        --enable-module=autoindex \
        --enable-module=cgi \
        --enable-module=dir \
        --enable-module=env \
        --enable-module=headers \
        --enable-module=imap \
        --enable-module=log_config \
        --enable-module=negotiation \
        --enable-module=rewrite \
        --enable-module=setenvif \
        --enable-module=speling \
        --enable-module=status \
        --enable-module=info \
        --enable-module=unique_id \
        --enable-module=userdir \
        --enable-module=usertrack \
        --activate-module=src/modules/php3/libphp3.a

Also duerften
> mod_perl/1.21 
> mod_ssl/2.4.7 
> OpenSSL/0.9.4 
als Fehlerquelle ausscheiden. Ebenso ist 'DSO' als moegliche
Fehlerquelle ausgeschieden.

Es bleiben also 
> PHP/3.0.16 
oder der Apache selbst; hier koennte es z.B. (wild guess) 
Speicherverwaltungsprobleme beim Verarbeiten der htaccess-Direktiven
geben. Die include-Pfad-Angaben werden ja (so man absolute Pfade
eintraegt; und das ist bei uns z.B. der Fall) ziemlich lang:
buffer overrun?

Uns ist das Problem uebrigens als erstes im phpMyAdmin aufgefallen.
Ausserdem tritt das Problem bei uns deutlich haeufiger bei der
Verarbeitung von PHP-Dokumenten auf, die 'richtig was tun'.
Das widerum deutet ja eher in Richtung php, bzw. in Richtung
der Kommunikation zwischen PHP und apache?


> in beiden Verzeichnissen habe ich Unterverzeichnisse mit dem Namen
> "test" angelegt und folgende Dateien hineingelegt:
[... Testverfahren gesnipped ... ]
 
> Danach wieder zurueck zur ersten URL. An dieser Stelle bekomme ich nun
> die Fehlermeldung, dass das benoetigte File "<wilder asciisalat>" nicht
> gefunden werden konnte.
Bei uns tritt das Problem auch auf, wenn nur Dokumente aus 
demselben Verzeichnis aufgerufen werden. Mit dem Wechsel
zwischen '~irgendwas' und '/wasanderes/' wird der Fehler direkt
nichts zu tun haben, denke ich.
 

> Das ganze kann man nun ein wenig entschaerfen, indem man in die Datei
> /usr/local/htdocs/test/.htaccess die Zeile
> php3_auto_prepend_file none
... benutzen wir auf dem einen betroffenen Server nirgendwo.
Ich werde jetzt einmal Versuchen, die Einstellungen aus '.htaccess'
zu entfernen und direkt in die Definition des virtuellen Servers
einzutragen.

> Vielleicht hat auch jemand die Moeglichkeit, das genauer 
> nachzuvollziehen, wo genau der Fehler auftritt.
Hmmm. Wo sind die Leute, die sich im Apache-Source gut auskennen?


-Andreas


-- 
: Anti-Spam Petition:     http://www.politik-digital.de/spam/          :
: PGP-Key:                http://www.tse-online.de/~ab/public-key      :
: Key fingerprint:  12 13 EF BC 22 DD F4 B6  3C 25 C9 06 DC D3 45 9B   :