PHP5 "verschluckt" Fehlermeldungen?

[Michael]

Hallo,

ich habe Probleme mit PHP5 zu debuggen. Manche Fehler werden nicht angezeigt (auch im logfile steht dann nichts). Das Problem scheint immer dann aufzutreten wenn ein Parser-Fehler oder ein anderer Fehler der zum Skriptabbruch führt in einer Klasse auftritt.

Ich habe diese Einstellungen gesetzt:
ini_set('log_errors', 1);
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL|E_STRICT);

Btw. ich lade meine Klassen über eine _autoload()-Funktion. Weiss jemand Rat wie ich PHP überrede mir alle Fehler anzuzeigen/loggen?

Gruss
Michael

[rob]

Hi!

ini_set();

Es kann gut sein, daß dein Aufruf von ini_set() keine Wirkung zeigt.
Einige Variablen lassen sich per ini_set() nicht verändern. Bei deinen sollte das eigentlich möglich sein. Ich denke diese fallen alle unter PHP_INI_ALL.
Sollten einige davon jedoch unter PHP_INI_SYSTEM fallen, dann kannst du diese nur über eine Änderung in der php.ini verändern und nicht zur Laufzeit deines Scriptes.
Es könnte allerdings auch sein, daß dein Hoster die Funktion ini_set() einfach aus sicherheitsgründen deaktiviert hat. Das wäre ebenfalls denkbar.
Oder handelt es sich um deinen eigenen Server auf deinem eigenen Rechner?

Gruß, rob

[Michael]

Es kann gut sein, daß dein Aufruf von ini_set() keine Wirkung zeigt.
Es könnte allerdings auch sein, daß dein Hoster die Funktion ini_set() einfach aus sicherheitsgründen deaktiviert hat. Das wäre ebenfalls denkbar.

Das habe ich nachgeprüft, die gesetzten Werte sind aktiv. Durch E_ALL|E_STRICT bekomme ich brav gemeldet wenn ich z.B. undefinierte Variablen verwende. Setze ich error_reporting auf E_ERROR runter, kommen solche Warnungen nicht mehr.

Oder handelt es sich um deinen eigenen Server auf deinem eigenen Rechner?

Ich habe zwar Zugriff auf den Server, kann aber nicht an der PHP ini rumspielen, weil dann alle gehosteten Domains davon betroffen wären ;)

Gruss
Michael

[Marc Reichelt]

Hallo Michael,

Ich habe zwar Zugriff auf den Server, kann aber nicht an der PHP ini rumspielen, weil dann alle gehosteten Domains davon betroffen wären ;)

Aber zumindest via .htaccess (mit der Option php_flag) lässt sich hier einiges machen, was sich mit ini_set() nicht machen lässt. Im Übrigen bereits _vor_ der Ausführungszeit des Skripts.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Tom]

Hello,

Aber zumindest via .htaccess (mit der Option php_flag) lässt sich hier einiges machen, was sich mit ini_set() nicht machen lässt. Im Übrigen bereits _vor_ der Ausführungszeit des Skripts.

... aber hier nur EINE ZAHL als Parameter für die Fehlergruppen übergeben, und keine Konstanten.
Und müsste es nicht php_value heiße hier? Ist ja schließlich ein numerischer Wert.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Michael]

Danke an alle die geantwortet haben!

Ich konnte mein Problem jetzt in den Griff kriegen indem ich in der htaccess mit php_flag/value folgendes gesetzt habe:

php_flag display_errors on
php_flag display_startup_errors on
php_value error_reporting 17

Das Problem scheint zu sein wenn folgende Scriptcombo abläuft:

Skript a.php:
<?PHP
$nachladen = 'b.php';
echo 'Hier ist a.php vor require<br>';
require_once($nachladen);
echo 'Hier ist a.php nach require<br>';
?>

Skript b.php:
<?PHP
oops! ein syntaxfehler!
?>

Das erste echo in a.php wird ausgegeben, dann wird b.php included mit error, dieser Fehler zählt anscheinend als startup-error, obwohl a.php ja schon gelaufen ist und ich angenommen habe das sich startup nur auf den Zeitraum bezieht bis das Erste Statement ausgeführt wird. Es scheint aber so zu sein das jegliches Parsing zur Startup Phase zählt, egal ob schon Statements ausgeführt wurden oder nicht.

Gruss
Michael

[Tom]

Hello,

php_value error_reporting 17

Ist das nicht ein bisschen wenig Fehlermeldung?

Das Problem scheint zu sein wenn folgende Scriptcombo abläuft:

Skript a.php:
<?PHP
$nachladen = 'b.php';
echo 'Hier ist a.php vor require<br>';
require_once($nachladen);
echo 'Hier ist a.php nach require<br>';
?>

Skript b.php:
<?PHP
oops! ein syntaxfehler!
?>

Das erste echo in a.php wird ausgegeben, dann wird b.php included mit error, dieser Fehler zählt anscheinend als startup-error, obwohl a.php ja schon gelaufen ist und ich angenommen habe das sich startup nur auf den Zeitraum bezieht bis das Erste Statement ausgeführt wird. Es scheint aber so zu sein das jegliches Parsing zur Startup Phase zählt, egal ob schon Statements ausgeführt wurden oder nicht.

Früher war es so, dass require ein unbedingtes Laden verursacht hat. Man konnte es also nicht mit

if($a) require()

beindrucken. Unabhängig von $a wurde geladen.

Und das geschah zur Startup-Zeit; also noch bevor weiter geparst wurde, wurden _alle_ requires eingesammelt. Mit include konnte man auch bedingtes Laden verlangen.
Angeblich soll das jetzt nicht mehr so sein, angeblich kann man nun mit beiden bedingt laden.

Du könntest es ja mal ausprobieren, wo Du gerade dabei bist.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Michael]

php_value error_reporting 17
Ist das nicht ein bisschen wenig Fehlermeldung?

Jein :) Zum debuggen wär 4095 angebracht, aber zum benutzen reicht mir 17. Ich stelle den reporting level zur runtime hoch, je nachdem auf welcher Domain (Produktiv oder Test) der Kram läuft.
Ich möchte vermeiden das ich per-domain Einstellungen über zig Dateien verstreue, mir ist es lieber wenn ich alle Einstellungen am gleichen Ort treffe :)
error_reporting 17 scheint mir ein brauchbarer Kompromiss für die Startup-Phase (bis die config.php drankommt) der sowohl für Produktiv als auch Entwicklung brauchbar ist.

Früher war es so, dass require ein unbedingtes Laden verursacht hat. Man konnte es also nicht mit

if($a) require()

beindrucken. Unabhängig von $a wurde geladen.

Und das geschah zur Startup-Zeit; also noch bevor weiter geparst wurde, wurden _alle_ requires eingesammelt. Mit include konnte man auch bedingtes Laden verlangen.
Angeblich soll das jetzt nicht mehr so sein, angeblich kann man nun mit beiden bedingt laden.

if (false) require('b.php');

Ergebnis b.php wird *nicht* geladen (PHP 5.1.2).

Wenn bedingtes Laden nicht möglich wäre würde bei mir ohnehin nichts laufen, ich verwende require('fixer name'); nur um das allernötigste zu laden. Der Rest wird dann über den Umweg _autoload() automatisch nachgezogen wenn dann irgendwo im Code $obj = new MYCLASS(); oder ähnliches kommt (dann springt PHP automatisch in die _autoload() die sich dann Gedanken macht in welchem Skript wohl die Klasse steckt und das dann mit require() einbindet).

Gruss
Michael

[Sven Rautenberg]

Moin!

php_value error_reporting 17
Ist das nicht ein bisschen wenig Fehlermeldung?
Jein :) Zum debuggen wär 4095 angebracht, aber zum benutzen reicht mir 17. Ich stelle den reporting level zur runtime hoch, je nachdem auf welcher Domain (Produktiv oder Test) der Kram läuft.

Wieso denn dieses?

Wäre es nicht schlauer, im Skript überhaupt keine Änderung am error_reporting vorzunehmen, und die Einstellung (ob per .htaccess oder im VHost) individuell pro Server vorzunehmen? Ich würde jedenfalls so vorgehen. Alles andere scheint mir unnötig aufwendig.

- Sven Rautenberg

[Tom]

Hello,

Wäre es nicht schlauer, im Skript überhaupt keine Änderung am error_reporting vorzunehmen, und die Einstellung (ob per .htaccess oder im VHost) individuell pro Server vorzunehmen? Ich würde jedenfalls so vorgehen. Alles andere scheint mir unnötig aufwendig.

würde ich auch so sehen.
Und dann würde ich nicht mit dem Error Reporting rumspeilen, sondern display_errors usw. verwenden.

Dass der User die Fehlermeldungen später nicht mehr sehen soll, kann ich nachvollziehen. Aber wenn man ein System pflegen muss, benötigt man doch ein paar Hinweise.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Michael]

Wäre es nicht schlauer, im Skript überhaupt keine Änderung am error_reporting vorzunehmen, und die Einstellung (ob per .htaccess oder im VHost) individuell pro Server vorzunehmen? Ich würde jedenfalls so vorgehen. Alles andere scheint mir unnötig aufwendig.

Hm, ehrlich gesagt: Keine Ahnung, dafür kenne ich mich zuwenig mit der Serverseite aus.
Alle Einstellungen über die htaccess zu treffen wäre wohl machbar, gefällt mir aber nicht so gut weil ich dann Konfiguration mit festen Direktiven vermischen würde und dann bei einem Update Konfigurationseinstellungen migrieren müsste.
Oberhalb des document-root möchte ich lieber nicht herumbasteln (Server wird mit PLESK verwaltet).

Viel Konfiguration benötige ich eigentlich nicht, es beschränkt sich im wesentlichen auf die Angaben zu den zu verwendenden Datenbanken (es können mehrere pro Domain sein).

Wunschkonfiguration ist: Genau ein Ort an dem alle Konfigurationseinstellungen (die der Kunde/Benutzer *nicht* ändern kann) abgelegt sind und wo *nichts* anderes abgelegt ist.

Ich bin für jeden Vorschlag zu haben der mir die Arbeit vereinfacht :)

Gruss
Michael

[dedlfix]

echo $begrüßung;

Ich bin für jeden Vorschlag zu haben der mir die Arbeit vereinfacht :)

Die Produktiv-Einstellungen könntest du wie üblich in die .htaccess schreiben. Die Einstellungen für das Testen könntest du bedingt hinzufügen. Allerdings ist von den drei <If...>-Direktiven nur die <IfDefine> diejenige, die sich einigermaßen sinnvoll für dieses Vorhaben verwenden lässt. Nun muss nur noch auf der Entwicklungsumgebung der Apache mit -D ... gestartet werden.

Und dann gibt es ja auch noch die Warmduscher-Methode: Dokumentation mittels Kommenentar-Zeilen. Auch optische Abgrenzungen lassen sich damit gestalten.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

Weiss jemand Rat wie ich PHP überrede mir alle Fehler anzuzeigen/loggen?

Syntax-Fehler werden vor Übergabe der Steuerung an dein Script erkannt, weil dies bereits beim Parsen des Codes passiert. Deshalb kannst du nicht während der Laufzeit eines Scripts etwas einschalten wollen, wenn dieses bereits eine Totgeburt ist. Auch andere Parameter lassen sich aus gleichen oder ähnlichen Gründen nur vor der Ausführung ändern, beispielsweise short_open_tag oder magic_quotes_gpc. Eine Liste der Parameter inklusive der Orte, an denen sie geändert werden können, gibt es im Anhang des Handbuchs: php.ini directives.

echo "$verabschiedung $name";