vage meldingen PHP5

[Verwijderd]

Ik zit al een tijdje te stoeien met php5. (op linux). Er gebeuren rare dingen. Nu krijg ik:

code:

Warning: fwrite(): supplied resource is not a valid stream resource in /home/httpd/sites/devrw/root/include/general.php on line 121

Warning: fclose(): supplied resource is not a valid stream resource in /home/httpd/sites/devrw/root/include/general.php on line 122

maf is dat de melding veroorzaakt wordt door de functie debugprint, inderdaad in general.php:

PHP:

function debugprint($tekst) {
    if (DO_DEBUGGING) {
        global $debugPrintStartTime;
        $file = fopen($_SERVER['DOCUMENT_ROOT'].'/../logs/debugprint.log','a');
        $usec = round(microtime(TRUE) - $debugPrintStartTime,4); 
        fwrite($file,$usec. ' ' . $tekst."\n");
        fclose($file); 
    }
}

en diezelfde functie op allerlei andere plekken vlak daarvoor (in hetzelfde script!) wel prima zijn werk gedaan heeft... Dan kan dan toch niet ineens veranderen???

de melding die erna komt:

code:

Warning: Unknown list entry type in request shutdown (1069840282) in /home/httpd/sites/devrw/root/class/PersistentObject.php on line 108

Warning: Attempt to assign property of non-object in /home/httpd/sites/devrw/root/class/PersistentObject.php on line 115

zijn ook vaag... er lijken objecten spontaan van type te veranderen. Eerst dacht ik dat het met de nieuwe OOP aanpak van php5 te maken had, nu begint het meer en meer op een ordinaire bug in php te lijken, alhoewel hij natuurlijk nog steeds prima getriggerd kan worden door rare code ergens.

Heeft iemand anders dergelijke ervaringen met PHP5?

[Mafioso]

Weet je zeker dat php de file kan openen om te schrijven, daar lijkt het namelijk mis te gaan.
Staan bv de rechten van die file wel goed? of is $_SERVER['DOCUMENT_ROOT'] misschien toch wat anders dan je dacht?

Maak er anders dit eens van:

PHP:

$file = fopen($_SERVER['DOCUMENT_ROOT'].'/../logs/debugprint.log','a'); 
var_dump($file);

Wellicht dat er dan wat meer duidelijk wordt.

[ Voor 23% gewijzigd door Mafioso op 09-09-2005 08:33 ]

[Verwijderd]

en diezelfde functie op allerlei andere plekken vlak daarvoor (in hetzelfde script!) wel prima zijn werk gedaan heeft... Dan kan dan toch niet ineens veranderen???

jep, ik weet zeker dat met dat bestand niets mis is... Het wordt door andere scripts met exact dezelfde functie fijn geschreven. Het wordt zelfs door hetzelfde script eerder wel goed geschreven. Dat weet ik 100% zeker: heb het leeggemaakt, en zie meldingen verschijnen die kloppen met het script en stoppen op het moment van de php melding...
Tenzij de document root veranderd tijdens het script, (zou nog niet moeten kunnen??) of er ergens anders nog iets met het bestand gebeurt (en da's niet in mijn script) kan ik het niet verklaren...

[vargo]

Staat er misschien een 'lock' op het script de logfile? Ik heb zelf eens een uur zitten klooien met een CSV file welke in excel open stond.

[ Voor 12% gewijzigd door vargo op 09-09-2005 09:18 ]

[Janoz]

Probeer je foutmeldingen eens op E_ALL te zetten. Die meldingen geven aan dat het bestand niet geopend kon worden ($file is immers geen geldige resource). Misschien komt er in dat geval wel naar boven waarom fopen faalt.

[frickY]

Ik kan me enigzins voorstellen dat fopen op zn bek gaat over;

code:

$_SERVER['DOCUMENT_ROOT'].'/../logs/debugprint.log'

Gooi daar eens de realpath()-functie overheen.

Verder zeg je dat het script eerder wel goed naar dit bestand kan schrijven. Combineer dit met de post van vargo; Close je die file-pointer daarna wel?

[triet]

Sowieso is een beetje error-checking nooit overbodige luxe...

[Verwijderd]

triet schreef op vrijdag 09 september 2005 @ 09:59:
Sowieso is een beetje error-checking nooit overbodige luxe...

dat klopt natuurlijk ;-) Maar ik wilde de functie snel&simpel. Hij werkt ook in het begin van de uitvoering van eht script maar later niet meer, terwijl er aan het bestand niets veranderd. Er is ook nog zat schijfruimte vrij....

- fopen heeft geen probleem met het pad, ik schreef dat het eerder wel werkte: in hetzelfde script, zelfs in dezelfde uitvoering. er worden tientallen regels naar het logfile geschreven, voor het toch misgaat
- het bestand wordt keurig gesloten, zie code
- errror reporting op E_ALL zetten levert alleen heeel veeel extra notices op over heel andere niet geinitialiseerde variabelen. (Dat klopt op zich, het is PHP, geen java of C ;-)
- vardump in debugprint opnemen werkt niet lekker, omdat ik de debugprint (juist) ook gebruik voordat er uitvoer gemaakt is.

Inmiddels kan ik het niet meer reproduceren, maar gaat het op een andere manier mis. IE zegt 'action cancelled', wat wil zeggen dat php nu nog eerder op zijn bek gaat... Nog steeds worden er wel En ik dacht een handige debugprintfunctie te hebben om te kunnen debuggen. Dat werkt ook wel, er worden heel wat regels weggeschreven voor het mis gaat:

code:

root@uranium /home/httpd/sites/devrw/logs# wc -l debugprint.log
1261 debugprint.log

het lijkt alsof variabelen soms spontaan van type veranderen....

[WormLord]

Je weet dat fopen een boolean(false) terug geeft als de file niet geopend kan worden?
Het is volgens mij ook netter om hierop te controleren, voordat je de fwrite en fclose aan gaat roepen.
Hiermee krijg je dan meteen een goed pad in je code om dit probleem te debuggen.

Het word dan zoiets:

PHP:

<? 
function debugprint($tekst) { 
    if (DO_DEBUGGING) { 
        global $debugPrintStartTime; 
        $file = fopen($_SERVER['DOCUMENT_ROOT'].'/../logs/debugprint.log','a'); 
        if ($file !== false)
        {
            $usec = round(microtime(TRUE) - $debugPrintStartTime,4);  
            fwrite($file,$usec. ' ' . $tekst."\n"); 
            fclose($file);  
        }
        else
        {
            // hier wat code om te kijken waarom fopen fout ging...
        }
    } 
} 
?>

[ Voor 51% gewijzigd door WormLord op 09-09-2005 12:19 ]