Häufige Fehlermeldungen

Frage: Was ist das für ein @-Zeichen vor einigen Funktionsaufrufen?

Manche PHP-Anweisungen können Fehlermeldungen, Warnungen oder Hinweise generieren. Diese Meldungen werden bei der Ausführung von Scripten Bestandteil der Ausgabe, wo sie unter Umständen sehr stören können. Stellt man einem Funktionsaufruf ein @ -Zeichen voran, wird der Interpreter die Ausgabe der Meldung unterdrücken.

Wenn die Konfigurationsanweisung track_errors aktiv ist, werden die Meldungen stattdessen in der Variablen $php_errormsg hinterlegt.

Diese Eigenschaften von PHP sind im Kapitel Error Handling dokumentiert.

Frage: Warning: Supplied argument is not a valid File-Handle resource

Ein Script versucht mit einem Filehandle ( $fp ) zu arbeiten, welches das Resultat eines fopen() ist ( $fp = fopen("..", "r") oder ähnlich). Dieses Filehandle ist ungültig, z. B. weil die Datei nicht existiert oder die Zugriffsrechte das Öffnen nicht gestatten.

Das Script ist fehlerhaft, weil es nach dem fopen() nicht prüft, ob das fopen() erfolgreich war:

$fp = fopen(..., "r");

        /* Das fehlt zum korrekten Code:  */
        if (!$fp)
                die("Kann Datei ... nicht oeffnen.\n");

        /* Diese Anweisung macht dann Ärger */
        while($line = fgets($fp, 1000)) {
        ...
        } 

Frage: Fatal error: Maximum execution time exceeded

Mit Hilfe des Parameters max_execution_time in der php.ini lässt sich die maximale Laufzeit eines PHP-Scriptes in Sekunden festlegen. Der Interpreter beendet sich selbst, wenn ein Script mehr als die dadurch zugewiesene Zeit läuft.

Wenn kein safe_mode aktiviert ist, kann ein Script sich selbst dieses Laufzeit-Limit mit Hilfe der Funktion set_time_limit() neu setzen.

Frage: Supplied argument is not a valid MySQL result...

Die Funktion mysql_query() liefert als Ergebnis 0 bzw. false , wenn die gesendete Query ungültig oder syntaktisch falsch ist. Es ist notwendig, diesen Fall abzufangen um die Meldung zu verhindern. Mit den Funktionen mysql_error() und mysql_errno() kann man auf die letzte Fehlermeldung bzw. die letzte Fehlernummer des MySQL-Servers zugreifen, wodurch sich die Fehlerursache meist leicht ermitteln lässt.

Siehe hierzu " sql-fehlerbehandlung ".

Frage: Windows: Call to unsupported or undefined function: xy()

PHP für Windows ist modular aufgebaut, einige Funktionen (z. B. die IMAP -, die LDAP - oder die Grafik -Funktionen) sind standardmäßig nicht vorhanden. Die verschiedenen Module liegen als DLL-Dateien vor und müssen geladen werden. Dies kann teilweise zur Laufzeit mit Hilfe der Funktion dl() geschehen, oder aber durch die passenden Einträge im Abschnitt "Dynamic Extensions" in der php.ini (siehe auch: " php-ini "):

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
; directory in which the loadable extensions (modules) reside
extension_dir   =  d:\php4\extensions\

; if you wish to have an extension loaded automatically, use the
; following syntax:  extension=modulename.extension
extension=php_imap.dll 

Wird PHP als Webserver-Modul eingesetzt, muss der Webserver neu gestartet werden, um die Änderungen in der php.ini aktiv werden zu lassen. Sowohl in der Distribution von php4win als auch in den Windows-Binaries von PHP.net sind zahlreiche Extensions enthalten.

Frage: Unix: Call to unsupported or undefined function: xy()

Höchstwahrscheinlich wurde das Modul bei der Installation von PHP nicht mitkompiliert ...

Ein Blick in den entsprechenden Abschnitt im PHP-Manual verrät oft schnell, welche Einstellung man beim Kompilieren beachten sollte.

Wenn ein Neukompilieren von PHP nicht möglich/erwünscht ist, kann man zur Laufzeit eine kompilierte shared PHP-Extensions (*.so) einbinden. Diese Extensions können mittels phpize erstellt werden:

# Beispiel: calendar-Extension
$ cd php4/ext/calendar
$ phpize
Configuring for:
  PHP Api Version:   20020918
  Zend Module Api No:   20020429
  Zend Extension Api No:   20021010
$ ./configure
...
$ make
...
Libraries have been installed in:
   /home/user/src/php4/ext/calendar/modules
... 

Mittels dl() können diese Binaries dann in Scripten eingebunden werden.

Frage: Warning: xy() is not supported in this PHP build

Der Funktionsname ist PHP zwar bekannt (im Gegensatz zu " fehler-modul-windows "), aber der Funktionsaufruf wird in dieser Version von PHP nicht unterstützt. Das kann z. B. bei neuen Funktionen der Fall sein, die noch nicht auf Windows portiert wurden oder die auf Windows-Systemen prinzipiell nicht anwendbar sind.

Es kann sich auch schlicht um ein Versehen beim Kompilieren handeln, dann sollte ein Blick in das Bug-System Klärung verschaffen. So wurde z. B. in PHP 4.0.5 für Windows die Funktion crypt() im Build nicht berücksichtigt. In allen Versionen davor und danach ist sie aber enthalten.

Frage: MySQL-Server has gone away

Mögliche Ursachen dafür werden in der MySQL-Dokumentation in Kapitel 18.2.1 diskutiert. Die Fehlermeldung kann durch einen Idle-Timeout auf der Datenbankverbindung (8 Stunden) oder durch zu große Datenpakete beim Arbeiten mit BLOBs und TEXT-Feldern auftreten. In letzterem Fall empfiehlt die MySQL-Dokumentation das Setzen der MySQL-Konfigurationsvariablen max_allowed_packet=# auf einen großen Wert (einige MB).

Ein Benutzer berichtete vom Auftreten dieses Fehlers beim Arbeiten mit UPDATE-Anweisungen in einer breiten Tabelle, die auch bis zu 150 KB große TEXT-Felder enthielt. Abhilfe war hier das Auslagern der TEXT-Felder in eine separate Tabelle. Dies brachte zugleich auch einen großen Performancegewinn.

Frage: Unix: Call to unsupported or undefined function: OCILogon()

Wenn die Konfiguration von PHP mit --with-oci8 korrekt erfolgt ist, dann kann mit einiger Sicherheit angenommen werden, dass ORACLE nicht korrekt installiert wurde. Falls man die Fehlermeldungen von configure und make überlesen hat, ist es möglich, dass der Oracle-Support nicht oder nur fehlerhaft in PHP einkompiliert wurde. Dies geschieht meist dann, wenn man übersieht, dass die Headerdateien, die von PHP benötigt werden, in der ORACLE Clientinstallation nicht enthalten sind. Die Dateien befinden sich in $ORACLE_HOME/rdbms/demo/ und $ORACLE_HOME/rdbms/public/ .

Lösung: Nachinstallieren von Pro*C/C++ und der Demodateien aus der ORACLE-Server Distribution, danach Neukompilierung von PHP.

Frage: Warning: ORA-12154: TNS:could not resolve service name

Diese Meldung kann zwei Ursachen haben:

Der TNS/-Name , der bei der Verbindung zu einem ORACLE-Server benötigt und in OCILogon() übergeben wird ist falsch, oder der TNS/-Name ist in der Datei tnsnames.ora im Verzeichnis $ORACLE_HOME/network/admin/ nicht eingetragen.

Lösung: Der Eintrag in der Datei tnsnames.ora muss korrekt sein, was man mit tnsping oder SQL*Plus überprüfen kann. Dieser Eintrag muss dann genau so der Funktion OCILogon() übergeben werden.

Achtung: Kommt stattdessen die Meldung "oci_open_server: Error while trying to retrieve text for error ORA-12154" , so ist die Umbgebungsvariable ORACLE_HOME falsch oder nicht gesetzt. Der nächste Abschnitt enthält weitere Informationen zu Umgebungsvariablen.

Frage: Warning: ORA-12705: invalid or unknown NLS parameter value specified

Die in oracle-umlaute erwähnten Einstellungen sind nicht korrekt. Der Datenbankserver versteht entweder das Character Set nicht oder der Pfad in ORA_NLS33 ist nicht korrekt.

Frage: Warning: Cannot send session cookie - headers already sent ...

Wie bei allen anderen HTTP-Headern, darf auch vor dem Setzen von Cookies (Sessionfunktionen von PHP4 benutzen standardmäßig Cookies) kein einziges Byte des Codes an den Client gesendet werden. Erst wenn alle HTTP-Header gesendet worden sind, dürfen entsprechende Daten (z. B. HTML) gesendet werden.

Typische Stolperfallen sind Leerzeichen bzw. -zeilen vor dem ersten <? bzw. <?php Delimiter des Scripts oder mit include() oder require() importierte Scriptfragmente, die natürlich gar keine Ausgabe produzieren dürfen - weder vor dem ersten Delimiter, noch dazwischen, noch nach dem letzten.

Zusätzlich kommt durch die auto_prepend_file -Einstellung in der php.ini , bzw. in der Webserverkonfiguration, eine weitere potentielle Fehlerquelle hinzu.

Frage: Warning: Cannot add header information - headers already sent ...

Aufrufe von header() müssen vor allen anderen Ausgaben an den Client erfolgen. Es spielt keine Rolle, ob die Ausgabe durch einen HTML-Bereich vor dem Script oder durch das PHP-Script selbst entsteht. Dabei reicht als "HTML-Bereich" z. B. bereits ein einziges Leerzeichen vor dem öffnenden PHP-Tag ( " <?php" ).

Siehe auch " fehler-session-cookie ".

Frage: Warning: Wrong parameter count for xy()

Die Funktion xy() erwartet eine andere Anzahl an Parametern, als ihr im Aufruf mitgegeben wurden. So erwartet z. B. die Funktion date() einen und optional einen zweiten Parameter, da sie wie folgt definiert ist: date (string format [, int timestamp]) . Parameter in eckigen Klammern sind optional und können von rechts nach links weggelassen werden. D. h. sowohl date() (kein Parameter) als auch date('H:i', 1005698576, 15) (drei Parameter) erzeugen eine Warnung, weil die Zahl der Argumente nicht mit der Funktionsdefinition übereinstimmt. Gültig sind dagegen date('H:i') (ohne Timestamp) und date('H:i', 1005698576) (mit Timestamp).

Selbst definierte Funktionen reagieren nur allergisch, wenn sie mit weniger Parametern aufgerufen werden, als in der Funktionsdefinition vorgesehen. Optionale Parameter müssen mit einem Vorgabewert versehen werden, damit das funktioniert: function xy($var = "default") (Vorgabewerte sind nur bei Call-by-Value, nicht bei Call-by-Reference möglich).

Frage: Notice: Use of undefined constant ...

Es wird eine Konstante verwendet, obwohl diese nicht definiert ist. Aus purer Freundlichkeit nimmt PHP den Namen der Konstante (!) als eigentlich gemeinten Wert an, belässt es bei einem Hinweis und lässt das Script weiterlaufen. Häufig wird dieser Fehler beim Zugriff auf Arrays gemacht, indem der Schlüssel direkt in eckigen Klammern steht, statt korrekt in Anführungszeichen eingefasst zu werden:

$array[key]     // Falsch, wenn key keine Konstante ist
$array["key"]   // So war es gemeint
$array['key']   // Besser, da nichts ausgewertet werden muss
$array[12]      // Richtig, Zahlen als Key ohne Anführungszeichen

$array[$key]    // Ok: Zugriff per Variable
$array["$key"]  // Hier sind die Anführungszeichen unnötig
$array['$key']  // Falsch, Variable wird nicht ausgewertet

"$array[key]"   // Korrekt (!), da innerhalb eines Strings
"$array[$key]"  // Korrekt
"$array['key']" // Parse error! 

In neueren PHP-Versionen ist der Error reporting level defaultmäßig so eingestellt, dass eine Warnung ausgegeben wird. Das Script sollte unbedingt nachgebessert werden. Es ist zwar auch möglich, PHP auf einen niedrigeren Error reporting level zu konfigurieren ( error_reporting = E_ALL & ~E_NOTICE; ), aber das ist auf Dauer nicht empfehlenswert, da es nur die Ausgabe der Warnung unterdrückt, nicht aber die eigentliche Ursache des Problems beseitigt (außerdem dauert der Arrayzugriff ca. 4-5 mal länger!).

Frage: Notice: Undefined variable ...

Möglicherweise erscheint diese Meldung bei Scripten, die bisher unter älteren PHP-Versionen liefen und jetzt unter PHP 4.1.0 oder neuer eingesetzt werden. Grund dafür ist häufig das ab dieser Version defaultmäßig strenger eingestellte error_reporting in der php.ini .

Der Hinweis wird ausgegeben, weil mit einer nicht definierten Variablen hantiert wird, d. h. der Name der Variablen existiert nicht, ein konkreter Wert ist folglich auch nicht verfügbar. Durch die automatische Typ-Konvertierung wird der angenommene "Wert" NULL dann zwar in einen passenden Datentyp verwandelt - das ist aber nur ein "Notbehelf", damit das Script weiterlaufen kann.

Wenn PHP mit register_globals = off konfiguriert ist, dann werden Variablen aus Formularen (oder aus dem Query-String im URL) nicht automatisch als $variable verfügbar gemacht. Diese Trennung zwischen Script-Variablen und Input-Variablen hat den Vorteil, dass nicht durch Aufruf von z. B. script.php?login=true die Script-interne Variable $login überschrieben wird.

Handelt es sich um Variablen, die per GET oder POST übergeben werden, und PHP läuft mit der Einstellung register_globals = off , dann ist es aus Sicherheitsgründen zu empfehlen, das Script an die neuen Variablennamen anzupassen ( $HTTP_GET_VARS/$HTTP_POST_VARS bzw. $_GET/$_POST , siehe: Release Notes zu PHP 4.1.0 ).

Handelt es sich um Script-interne Variablen, sollten diese vor der Verwendung definiert werden. Bevor man also $foo .= "bla"; schreibt, um an $foo etwas anzuhängen, ist ein $foo = ""; nötig, um die Variable zu definieren und ihr einen leeren String zuzuweisen.

Möchte man optionale Variablen (z. B. Checkboxen aus einem Formular) abprüfen, sollte man isset() verwenden, um auf die Existenz der Variablen zu testen:

// Nicht empfohlene Schreibweisen
if ($checkbox)
if ($var == 'wert')

// Empfohlene Schreibweisen
if (isset($_POST['checkbox']))
if (isset($_POST['var']) && $_POST['var'] == 'wert') 

Es ist zwar auch möglich, PHP auf einen niedrigeren Error reporting level zu konfigurieren ( error_reporting = E_ALL & ~E_NOTICE; ), aber das ist auf Dauer nicht empfehlenswert, da es nur die Ausgabe der Warnung unterdrückt, nicht aber die eigentliche Ursache des Problems beseitigt.

Frage: Warning: Failed opening 'xy' for inclusion ...

Dieser Fehler kann mehrere Ursachen haben:

• Die Datei xy existiert nicht (möglicherweise ein Pfad-Problem)

• xy ist eine lokale Datei, an die Parameter angehängt wurden - siehe hierzu: " datei-uebergabe "

• PHP kann die Datei xy nicht lesen, weil es nicht die erforderlichen Rechte für die Datei hat (der Fehler tritt dann angeblich in Zeile 0 auf)

• xy ist ein URL, allow_url_fopen steht aber auf 0 (siehe phpinfo() )

• xy ist ein URL und wird mit include() unter Windows benutzt; das wird zumindest derzeit nicht unterstützt

All diese Probleme können analog auch mit require() auftreten, nur dass die Fehlermeldung dann Fatal error: Failed opening required 'xy' ... lautet.

Frage: Parse error: parse error in ...

Der PHP-Code enthält (mindestens einen) Syntax-Fehler. Der PHP-Parser kann den Code nicht interpretieren und stellt die Arbeit ein.

Die in der Fehlermeldung angegebene Zeilennummer muss dabei nicht unbedingt exakt die Zeile sein, in der sich der Fehler befindet; vielmehr kann der logische Fehler auch eine oder mehrere Zielen davor passiert sein, in der angegebenen Zeile tritt jedoch der syntaktische Fehler auf. Beispiel:

<?php
echo "H;    // Anführungszeichen vergessen
dies();
das();
?>          <-- hier tritt der Fehler auf! 

Häufig sind vergessene Anführungszeichen oder nicht richtig geschlossene runde oder geschweifte Klammern die Ursache für Parse errors. Man sollte diese Zeichen immer paarweise schreiben und erst dann mit Inhalt füllen (also echo "" und dann zwischen die Anführungszeichen schreiben) und/oder einen Editor verwenden, der durch farbliche Markierung auf solche Unstimmigkeiten hinweist. Ein beliebter Fehler ist auch ein vergessenes Semikolon am Zeilenende.

Frage: 0 is not a MySQL result index

Siehe fehler-mysql-result .

Frage: Warning: Unknown error ...

Tja, ein "unbekannter Fehler". Dieser Fehler kann vermutlich mehrere Ursachen haben, ein bekannter Fall ist die Verwendung der Funktion mail() ohne installierten (korrekt konfigurierten) Mailserver. Siehe hierzu auch: " mail-server ".

Frage: Warning: Failed to Connect ...

Vermutlich wurde die Funktion mail() ohne installierten (korrekt konfigurierten) Mailserver aufgerufen. Siehe hierzu auch: " mail-server ".

Frage: Warning: open(/tmp\sess_..., O_RDWR) failed ...

Der Pfad für die Speicherung der Session-Daten lautet defaultmäßig /tmp , unter Windows muss der Pfad aber mit einem Laufwerksbuchstaben angegeben werden. Siehe " sessions-windows ".

Frage: Warning: fopen() - No such file or directory

Diese Warnung besagt, dass die Datei oder das Verzeichnis, das mit fopen() geöffnet werden soll, nicht existiert.

Die Ursache dafür kann vielfältig sein:

1. Die Datei, die geöffnet werden soll, existiert nicht.

   Dies passiert besonders häufig beim Zugriff auf URLs. Prüfen lässt sich die Existenz mit einem Browser. Der häufigste Fehler ist die Verwendung von relativen URLs. Richtig sind absolute URLs, die mit http:// oder ftp:// beginnen.

   Quellcode-Beispiele:

   <?php /* Die externe URL http://www.example.com/verzeichnis/datei.ext soll gelesen werden. */ /* in diesem Fall falsch, da eine URL absolut angegeben werden muss dieses Beispiel würde versuchen, die Datei datei.ext in /verzeichnis auf dem eigenen Server zu öffnen. */ $fp = fopen("/verzeichnis/datei.ext", "r"); /* richtig */ $fp = fopen("http://www.example.com/verzeichnis/datei.ext", "r"); ?>

2. Das Verzeichnis existiert nicht.

   fopen() erstellt keine Verzeichnisse, wenn diese fehlen. Im Gegensatz dazu werden fehlende Dateien von fopen() automatisch angelegt, wenn sie zum schreiben geöffnet werden.

   Häufig wird in ChangeRoot-Umgebungen gearbeitet. Dies hat zur Folge, dass das Root-Verzeichnis des Users (z. B. /home/user/) von der Server-Root abweicht (/). Genaueres erfährt man durch die Verwendung von phpinfo() .

   Quellcode-Beispiele:

   <?php /* die DocumentRoot sei /home/user und die zu öffnende Datei file.ext im Verzeichnis mydir */ /* falsch */ $fp = fopen("/mydir/datei.ext", "r"); /* richtig */ $fp = fopen("/home/user/mydir/file.ext", "r"); ?>

   Desweiteren kann es vorkommen, dass sich Tippfehler im Pfad befinden. Ein häufig übersehener Fehler sind Leerzeichen am Anfang, im Pfad oder an dessen Ende.

   Code-Beispiele:

   <?php /* falsch, Leerzeichen am Anfang */ $fp = fopen(" /verzeichnis/datei.ext", "w"); /* falsch, Leerzeichen im Pfad */ $fp = fopen("/verzeichnis/ datei.ext", "a+"); /* falsch, Leerzeichen am Ende */ $fp = fopen("/verzeichnis/datei.ext ", "r+"); /* richtig */ $fp = fopen("/verzeichnis/datei.ext", "w"); ?>

Frage: Warning: fopen() - No error

Es kann unter bestimmten Umständen vorkommen, dass PHP im Zusammenhang mit dem Befehl fopen() die Warnung "No error" oder "Success" ausgibt, was sich natürlich paradox anhört. Der Grund ist, dass beim Ausführen von fopen() zwar ein Problem auftrat, aber keine näheren Informationen über die Art des Problems vorliegen. Meist handelt es sich dabei um folgende HTTP-Status-Codes, die fopen() nicht verarbeiten kann:

• Die angeforderte Ressource liegt in einem mittels HTTP Basic Authentication geschützten Bereich (Status-Code 401)

• Es erfolgt ein nicht RFC-konformer Redirect. Korrekte Redirects mit absoluter URL kann fopen() jedoch handhaben (Status-Code 301 oder 302)

• Die Ressource ist nicht vorhanden (Status-Code 404)

• Der Zugriff ist verboten (Status-Code 403)

Frage: Document contains no data

Dies ist eine Netscape-Fehlermeldung, die dann auftritt, wenn der Webserver als Antwort auf einen Request genau Null Bytes Antwort liefert. Wenn dies geschieht und die Seite eigentlich eine Ausgabe erzeugen sollte, dann hat möglicherweise der PHP-Interpreter ein Problem und stürzt mit einem Coredump ab.

Der Microsoft Internet Explorer hat die Eigenart, in der Quelltext-Ansicht statt einer leeren Seite ein HTML-Grundgerüst zu präsentieren, das nicht vom Server stammt, sondern vom IE generiert wurde.

Handelt es sich um ein PHP-Problem, sollte man versuchen, den Fehler zu reproduzieren und das kürzestmögliche (!) Script, das den Fehler erzeugt, in den Bugreport mit einbinden.

Frage: Parse error on line 1 ... (bei Verwendung von XML/XHTML)

Im Normalfall erlaubt PHP den Skriptbereicht mit <? ?> (den sogenannten Short-Tags) einzugrenzen, da diese Variante schneller zu schreiben ist - als <?php ?> - und man außerdem einfach Variablen ausgeben kann ( <?=$variable ?> ). Für PHP ist es aber unmöglich diese Notation von einer XML-Deklaration ( <?xml version="1.0" ?> ) zu unterscheiden; der Parser glaubt daher, dass es sich hierbei um PHP-Code handelt, der natürlich syntaktisch nicht korrekt ist.

Um das Parsen der Short-Tags abzuschalten, muss man den Eintrag short_open_tag in der php.ini auf off setzen. Danach wird nur mehr Code innerhalb der XML-konformen Processing Instructions (PI) <?php ?> bzw. dem <script language="php"> ... </script> Tag interpretiert.

Alternativ kann man natürlich auch die XML-Deklaration mittels echo ausgeben:

<?php echo '<?xml version="1.0" ?>'; ?> 

Frage: Fatal error: Cannot redeclare class ... in ... on line ...

In den meisten Fällen werden immer wieder verwendete Funktionen und Klassen in seperate Dateien geschrieben und diese dann über include oder require in das Programm eingebunden. Wird über include oder require eine solche Datei zweimal geladen, wird der darin enthaltene Code auch zweimal ausgeführt. Das aber führt auf Grund der Redefinition der Funktion(en) und/oder Klasse(n) zu einem Fehler. Um diesen Fehler zu vermeiden, muss include_once() oder require_once() verwendet werden. Include_once und require_once verhalten sich beim ersten Aufruf wie include und require, bei wiederholtem Aufruf wird jedoch ein erneutes Laden der gleichen Datei verhindert.

Frage: Fatal error: Cannot redeclare ... (previously declared in ...) in ... on line ...

Siehe fehler-class-redeclare .