[PHP]probleem met debugging code error 500

[djluc]

Ik ben bezig met het opzetten van een totaal systeem waarin een aantal applicaties zitten. Ik heb ondertussen al een deel van het cms en een mail applicatie.

Opeens is de applicatie er mee gestopt, ik krijg meteen een error 500 voor mijn neus. In de log bestanden krijg ik de melding PHP premature end of script headers. Er is dus verder geen enkele foutmelding, een linenumber of wat dan ook. Meteen daarna verschijnt de melding: php heeft een fout veroorzaakt in php4ts.dll. Het OS is WinME. Ik heb ook op andere systemen getest(w2k server) en daar gebeurt hetzelfde dus het is een scriptfout lijkt mij. Hoe pak je dit debuggen aan?

Ik heb geprobeerd om stukjes code er uit te knippen, en dat heeft wat resultaten opgeleverd:
Ik heb dit stukje verwijderd:

PHP:

/****APPLICATIONS MENU****/
/****HIDING UNUSED BLOCKS****/
foreach($_SESSION['applications'] as $appname => $apparray){
    if($_SESSION['applications'][$appname]['intern']!=1){
        /*PARSING menu*/
        $tpl->set('menulink', './index.php?app='.$appname);
        $tpl->set('menutext', ucfirst(strtolower($apparray['menuname'])));
        $tpl->parse('menuitem');
    }
    /*HIDING unused blocks*/
    if($appname!=$_SESSION['application']){
        $tpl->replace($appname, 'empty');
    }
}
$tpl->parse('menu');

Het resultaat daarvan is dat de template engine(yapter v213b, v212 geeft een echt 500 terug waarschijnlijk omdat deze geen melding maakt van ongedeclareerde variablen) begint te zeuren over allerlei variablen die niet gedeclareerd zijn, logisch, maar daarna klapt het script er alsnog uit.

Hoe kan ik gaan zoeken naar de fout?
update:Ik heb net geprobeerd om een print_r van $_SESSION te doen en die wordt op de helft afgebroken waarna die PHP heet een fout veroorzaakt melding verschijnt.

[ Voor 44% gewijzigd door djluc op 16-08-2003 10:29 ]

[Spider.007]

heb je hier al tussen gekeken? Het is inderdaad erg lastig debuggen zo; heb je niet een klein stukje code wat de fout op zichzelf ook al veroorzaakt (dus als je alleen dat stuk code draait?) Dat is dan te testen op een andere bak

[djluc]

Spider.007 schreef op 16 August 2003 @ 10:34:
heb je hier al tussen gekeken?

uiteraard Maar de resultaten gaan vrijwel alleen maar over installatieproblemen. En er is helemaaql niets aan de installatie veranderd.

Het is inderdaad erg lastig debuggen zo; heb je niet een klein stukje code wat de fout op zichzelf ook al veroorzaakt (dus als je alleen dat stuk code draait?) Dat is dan te testen op een andere bak

Zoals je waarschijnlijk wel zult begrijpen hangt alle code samen. Je mag er van uit gaan dat de code in de functie natuurlijk sowieso samenhangt.

Ik heb zeer erg de neiging om gewoon opnieuw te gaan beginnen, hoe zonde dat ook is van mijn tijd. Ik ben nu al 2 dagen bezig met het zoeken maar hiet wordt je echt niet happy van. Ik heb geprobeerd om dat Zend programma te installeren maar dat werkte niet. Daar zit een of andere debug functie in schijnbaar, die wilde ik eens gaan proberen.

[Spider.007]

djluc schreef op 16 August 2003 @ 10:41:
[...]
uiteraard Maar de resultaten gaan vrijwel alleen maar over installatieproblemen. En er is helemaaql niets aan de installatie veranderd.

Fijn dat je zelf ook al hebt gezocht Heb je hier al naar gekeken Daar zie ik staan dat er naast ZEND ook alternatieve debuggers bestaan. Ik heb hier zelf geen ervaring mee; maar ga ervan uit dat ze onder andere aan kunnen geven welke script regel momenteel wordt uitgevoerd; zodat je kunt zien waar het script precies vastloopt.

[...]

Zoals je waarschijnlijk wel zult begrijpen hangt alle code samen. Je mag er van uit gaan dat de code in de functie natuurlijk sowieso samenhangt.

Ik heb zeer erg de neiging om gewoon opnieuw te gaan beginnen, hoe zonde dat ook is van mijn tijd. Ik ben nu al 2 dagen bezig met het zoeken maar hiet wordt je echt niet happy van. Ik heb geprobeerd om dat Zend programma te installeren maar dat werkte niet. Daar zit een of andere debug functie in schijnbaar, die wilde ik eens gaan proberen.

Het kan frusterend zijn om een dergelijk moeilijke fout te debuggen. Ik heb zelf toevallig ook dagen gestoken in het opsporen van een memory leak (mijn PHP site zorgt ervoor dat Linux 350 Mb aan buffers gaat gebruiken ) en heb dit nog steeds niet opgelost.... Als je meer tijd in het debuggen dan het programmeren hebt gestopt kan het verstandig zijn opnieuw te beginnen; zij (?) het niet dat je dan tegen hetzelfde probleem aan kunt lopen....

[djluc]

Spider.007 schreef op 16 August 2003 @ 10:53:
[...]


Fijn dat je zelf ook al hebt gezocht Heb je hier al naar gekeken Daar zie ik staan dat er naast ZEND ook alternatieve debuggers bestaan. Ik heb hier zelf geen ervaring mee; maar ga ervan uit dat ze onder andere aan kunnen geven welke script regel momenteel wordt uitgevoerd; zodat je kunt zien waar het script precies vastloopt.

Zoals je waarschijnlijk wel zult begrijpen heb ik zonder een regenummer niet een klein stukje code bij de hand waar ik het kan vinden. Dan had ik het waarschijnlijk ook al wel opgelost.

Ik ben nu even aan het kijken naar die adere debuggers. Maar sommige moet je zelf in de source compilen, en dat kan ik niet.

[...]
Het kan frusterend zijn om een dergelijk moeilijke fout te debuggen. Ik heb zelf toevallig ook dagen gestoken in het opsporen van een memory leak (mijn PHP site zorgt ervoor dat Linux 350 Mb aan buffers gaat gebruiken ) en heb dit nog steeds niet opgelost.... Als je meer tijd in het debuggen dan het programmeren hebt gestopt kan het verstandig zijn opnieuw te beginnen; zij (?) het niet dat je dan tegen hetzelfde probleem aan kunt lopen....

350mb loopt inderdaad niet echt lekker.
Ik zit er over te denken om te beginnen met het zoeken van een standaard framework, en daarin mijn cms e.d. te gaan bouwen.

[Apache]

K'heb er zo ook al gehad, meestal gedebugged met de meest primitieve methode, en dat is gewoon na elk blok code waar het mogelijk fout kan gaan wat te printen.

PHP:

<?php
print('Gets here: '. __FILE__ .'('. __LINE__ .')<br>\n');
?>

Wel vaag dat hij midden in een print_r stopt, misschien is deze methode dan ook niet erg doeltreffend.

[djluc]

Ik denk dat ik het probleem gevonden heb, ik ben trouwens opnieuw begonnen met een nieuwe versie die beter is. Iets netter gecoded

Als ik een verkeerde bron opgeef voor een foreach lus gaat het fout. Ik heb trouwens een nieuwe install gedaan met phpdev 5. Ik vind het zomaar vreemd dat ik dan niet een foutmelding krijg, bug?

[Spider.007]

djluc schreef op 22 August 2003 @ 16:26:
Als ik een verkeerde bron opgeef voor een foreach lus gaat het fout. Ik heb trouwens een nieuwe install gedaan met phpdev 5. Ik vind het zomaar vreemd dat ik dan niet een foutmelding krijg, bug?

Als je met een development versie bezig bent geweest is dat wel te begrijpen. Je zou hier een bug kunnen submitten

[djluc]

Sorry, ik lees net de readme, doe ik anders ook nooit:

Note that you will see many phpdev5 references and some phpdev5 images in this bundle, sorry just no time to change them, this is not phpdev5 it is phpdev423, and if you think my versioning sucks then you would be right.

Hoezo slordig...

Maargoed het is dus PHP 4.2.3 dus dat mag het probleem niet zijn.

[Spider.007]

Kun je dan toch niet beter een stable versie pakken? Of begrijp ik je verkeerd en ben je nu niet aan het ontwikkelen onder een development PHP versie

[djluc]

Ik dacht dat 4.2.3 stable was? Ik heb net even geprobeerd om de 4.3.2 insatller te draaien maar dan begint de Zend optimizer weer te zeuren dat hij ook geupdate wil worden dus dat ga ik doen nadat ik het product wat ik nu aan het ontwikkelen ben af heb.