[PHP] script stopt nogsteeds zonder waarschuwing

[anonimoes]

Helaas ben ik weer terug, met nogsteeds hetzelfde probleem als voorheen... (klik)

Wat is het probleem? Ik heb een php script gemaakt die een htlm pagina output met invulvelden waarmee mensen zich in kunnen schrijven voor een wedstrijd. Deze input moet vervolgens gecheckt worden op leeg gelaten velden en velden die numeriek moeten zijn e.d. Tot daar gaat alles goed. Zolang iemand in 1 keer alle info goed invult dan gaat er ook niks fout en krijgt die persoon een overzich van de net ingevulde gegevens te zien en de mogelijkheid om deze te bevestigen waarna de aanmdeling afgerond wordt. Het gaat dan om deze pagina.

Waar het wel fout gaat is als de input niet meteen goed is. Het formulier moet dan opnieuw weergegeven worden met alle ingevoerde gegevens erin en een foutmelding bij het veld of de velden die verkeerd waren ingevoerd zodat men dit kan verbeteren. Bij de meeste invulvelden gaat dit ook gewoon goed overigens. Pas als er echt meerdere velden niet ingevuld worden gaan er gegarandeerd problemen optreden: Het 'correctieformulier' wordt dan maar gedeeltelijk weergegeven waardoor het niet verder gebruikt kan worden (er ontbreken velden en o.a. de submit knop). Als ik slechts 1 veld per keer leeg laat en dus een error laat geven dan wordt alleen bij de leeggelaten velden 'city', personal best STA (zowel minuten als seconden) en Announcement DYN/DNF een onvolledig formulier weergegeven.

Het vreemde is wel dat er dan niet direct onder de velden die een fout geven afgebroken wordt maar pas een stuk verderop...

Waar ik zelf al aan gedacht heb:
- geheugenprobleem: dit is m.i. niet zo, als ik namelijk erg veel data output (zoals postdata ofzo) dan gaat hij soms ineens ook weer meer van het script weergeven.
- Alles is netjes met aanhalingstekens e.d. omgeven. (tip uit vorige topic, was niet helemaal netjes gedaan nog)
- het verwijderen van de echo tussen de <?php en ?> tags waardoor er alleen een leeg stukje staat zorgt ervoor dat het hele script doorlopen wordt.
- het verwijderen van het hele stukje php laat wel het hele script doorlopen
- wanneer ik echo(functie) vervang door letterlijk echo("bla"); dan gaat het ook goed
- aan de executiontime ligt het ook niet (die staat op oneindig nu, tip uit vorige topic. Dit was echter nooit een issue omdat de executiontime < 1s bedraagt.)
- het stukje waar hij vastloopt precies hetzelfde maken als een stukje waar hij niet vastloopt heeft geen effect.

Zoals in mijn vorige topic te lezen was had ik veel last van php notices na het aanzetten van E_ALL in de error reporting. Deze zijn inmiddels allemaal weggewerkt en ik krijg ook geen enkele foutmelding als mijn script vastloopt. Tijdens het maken van de output voor het 'verbeterformulier' gebruik ik plain html met daartussen stukjes php die functies aanroepen. In deze stukjes php geeft het script er de brui aan. Hieronder een voorbeeld van hoe de functies in kwestie eruit zien en hoe deze aangeroepen worden:

PHP:

<?php
function checked($input1, $request, $index)
    {
    if (isset ($request[$index]) && $input1 == $request[$index]) $return = "CHECKED";
    else $return = "";
    return $return;
    }

function view_error($error, $indexes)                   // functie definieren om uniforme errormessages te genereren
    {
    foreach ($indexes as $index)
        {
        if (isset($error[$index]) && strlen($error[$index]) > 0)
            {
            $output = (!isset($output)) ? '</tr><tr><td class="error"><td class="error">' : $output.'';
            $output .= '<b> Notice: </b>' . $error[$index] . '<br />';
            }
        }
    if (isset($output)) return $output . '</td>';
    }

?>

<tr> 
        <td class="head">Announcement STA </td> 
        <td class="form">       <input size="1" type="text" value=<?php echo (view_input($_REQUEST, "ap_sta_m"));?> name="ap_sta_m" maxlength="2">:<input size="1" type="text" value=<?php echo (view_input($_REQUEST, "ap_sta_s"));?> name="ap_sta_s" maxlength="2"> 
                                (mm:ss) </td>
        <?php echo(view_error($error, array("ap_sta", "ap_sta_num")));?>
</tr> 
 <tr> 
        <td class="head">DYN or DNF? </td>
        <td class="form">       <input style="border: 0px;" type="radio" value="dyn" name="dyndnf" <?php echo(checked("dyn", $_REQUEST, "dyndnf"));?>> Dynamic (with fins)<br />
                                <input style="border: 0px;" type="radio" value="dnf" name="dyndnf" <?php echo(checked("dnf", $_REQUEST, "dyndnf"));?>> Dynamic no fins </td>
        <?php echo(view_error($error, array("dyndnf")));?>
</tr>

Op de stukjes php met de "view_input" functie loopt het script niet vast, wel op de stukjes met de "checked" en "view_error" functies. Deze functies worden voordat het script vastloopt echter al vele malen gebruikt zonder problemen te geven. Het lijkt bovendien echt aan de plek in de code te liggen aangezien het probleem blijft bestaan als ik het stukje gelijk maak aan een stukje er net boven. Ik zie echter niet in waarom dit stukje nu ineens wel een fout zou geven. Wat het geheel helemaal bizar maakt is dat php er nergens over klaagt...

Samengevat: Ik kan de vinger niet op de zere plek leggen, het script loopt vast zonder foutmelding in code die identiek is aan andere code waar wel gewoon goed mee omgegaan wordt. Mijn vraag nu is dan ook of jullie een idee hebben waar het aan zou kunnen liggen. Overigens: tussen het vorige topic en dit topic zijn de aangeroepen functies van opbouw veranderd en nog steeds blijft het probleem bestaan.

[Koetjeboe]

Op regel 26, die php code op het einde van de regel is niet afgesloten, klopt dit of is het gewoon fout gekopieerd?

[ Voor 16% gewijzigd door Koetjeboe op 18-06-2008 21:35 ]

[Gomez12]

Wat is $error? Zie ik nergens gedefinieerd staan, moet in dit script minimaal een notice opleveren volgens mij...

[SchizoDuckie]

Sorry hoor, maar je hebt nog steeds niet gekeken wat er gebeurt volgens mij als je set_time_limit(0) doet. Volgens mij roep je gewoon recursief ergens een ranzige loop aan.

Post je hele script eens voor de gein (plaats een .phps online ergens als het > 50 regels is), met een half script demo script zoals dit kunnen we ook weer net niets.

Verder heb je ook nog een view_input functie die nergens gedefinieerd staat, hoort isset($error[$index]) volgens mij array_key_exists($index, $error) te zijn, en zijn er vast nog wel at dingetjes te vinden....

Een andere simpele debug truc is de volgende: Strip je script net zo lang van functionaliteit tot het niet meer vastloopt. Maak daarna je laatste wijziging ongedaan en werk vanaf daar verder.

Ook moet je denk ik niet alleen letten op je php errors/notices maar ook je error.log nakijken, apache logs en eventuele mysql logs.


[edit]
Het zal waarschijnlijk niet veel helpen, maar het is überhaupt netjes om zowiezo een waarde te returnen als je strings aan elkaar plakt. Je view_error functie doet dat nu niet. Probeer het eens zo?

PHP:

function view_error($error, $indexes)        
{
    $notices = '';
    foreach ($indexes as $index)
    {
        $notices .= (array_key_exists($index, $error) && strlen($error[$index]) > 0) ?  '<b> Notice: </b>'.$error[$index].'<br />' : '';
    }
    return( $notices != '' ? '</tr><tr><td class="error"><td class="error">'.$notices.'</td>' : ''); // note: ik heb hier je dikke html error laten zitten :P
}


function checked($input1, $request, $index)
{
    return( (array_key_exists($index, $request) && $input1 == $request[$index]) ? "CHECKED" : "");
}

[ Voor 76% gewijzigd door SchizoDuckie op 18-06-2008 22:48 ]

[anonimoes]

@Koetjeboe: Eh, inderdaad verkeerd gekopieerd vanuit joe in de console, dan neem je wat niet op het scherm staat niet mee... Is nu iig gefixed.
@Gomez12: $error wordt eerder in het script gedefinieerd, ik heb hier enkel de stukjes code laten zien die, naar mijn idee, de problemen opleveren.
@Schizoduckie: De set_time_limit(0) staat sinds jij het gesuggereerd hebt bovenaan mijn script dus daar kan het echt niet aan liggen. Loopen is imho onwaarschijnlijk maar wellicht dat ik te onervaren ben wat dat betreft... Ik heb wel eens eerder een loop gehad en dat ging heel anders dan hoe dit gaat.

Ik zou heel graag het hele script plaatsen (in een bestand is inderdaad beter dan hier op het forum plakken) maar ik weet niet of de mods daar blij mee zijn aangezien mijn vorige topic daarvoor dicht ging... Als Creepy of een andere mod dit leest: mag dit nu wel of niet? Ik kom hier echt niet omdat dit lekker makkelijk is maar alleen omdat ik er zelf echt niet meer uitkom. Ik programmeer alweer heel wat jaartjes php, welliswaar niet op een heel hoog niveau, maar ik ben er tot op heden altijd zelf uitgekomen zonder hulp van GOT.
Mocht ik toestemming krijgen om het volledige script hier kenbaar te maken dan zal ik dat deze keer doen middels een bestand op de server waar ik op werk en niet meer hier alles in het forum kopieren.

Het strippen van functionaliteit is inderdaad een goede optie maar in feite heb ik dat al gedaan. Zodra ik het stukje php code tussen de plain html weghaal is het probleem opgelost, het zal dus ergens in de functie liggen denk ik... Of zie ik dit verkeerd? Ik zal iig jouw suggestie van array_key_exists eens proberen. En ik zal ook naar de logs gaan kijken op de server zelf.

[Gomez12]

Strippen van de code heb je nog niet genoeg gedaan als je nog niet op minder dan 50 regels zit en het probleem zich nog steeds voordoet.

Probeer anders een ipv strippen je code opnieuw op te bouwen in een nieuw bestand. Eerst dump je alle functies erin, gaat dit goed dan copieer je er wat functie aanroepen in op dezelfde manier als waarop je het nu hebt staan.

Sowieso kan je alle html er al uitgooien.

Of zoals je het zelf zegt, als het wel werkt als je de plain html code + php weglaat, dan kan je in wezen gewoon letter voor letter de code weer toevoegen, dan loopt hij op een gegeven moment vast en dan haal je de laatste letter weg en print je eventjes alle variabelen...

P.s. je register_globals staan toch wel uit he...

[anonimoes]

@ Gomez12: dat nagaan van waar het probleem zich voordoet heb ik eigenlijk al compleet gedaan, het gebeurd pas als ik de echo iets uit de functie wil laten printen... Wat register_globals betreft kan je gerust zijn hoor Ik programmeer dan wel niet op een erg hoog niveau maar dat staat toch zeker uit.

@all: Ik heb toch eerst de logs er eens op nagekeken en in de apache errorlog kom ik segfaults tegen. Als ik het script aanroep in mijn browser en het loopt vast dan komt er netjes voor elke keer F5 een segfault bij te staan in de logfile... Wat ik hieruit concludeer is dat er (dus) niks fundamenteel mis is met mijn code. (op schoonheidsfoutjes na) Dit heb ik ook meteen maar geprobeerd op een andere server en daar herhaalt het probleem zich niet. Het lijkt er dus op dat de kern van het probleem bij apache / php ligt. Dat ga ik nu dus eerst maar eens verder uitzoeken.

De precieze segfault is overigens deze, ter info:

code:

[Wed Jun 18 23:01:05 2008] [notice] child pid 12832 exit signal Segmentation fault (11)

[Gomez12]

Eventjes ter info, als het echt een bug in php is, dan verwachten ze daar ook een kort stukje code wat het probleem reproduceert.

Dus ik zou persoonlijk eerst nog even zelf doorzoeken naar een stukje reproduceerbare error-code...

[SchizoDuckie]

In dat geval is het meer likely dat je webserver hardware gewoon dood is. begin maar eens op www.memtest86.com

[Gomez12]

@SchizoDuckie waarom gelijk dode HW? Als ik eventjes op Google kijk dan vind ik meer Software fouten dan HW fouten.

En ik vermoed dat het testen op HW fouten ietsjes moeilijker is dan het testen op Software fouten...

[SchizoDuckie]

Gomez12 schreef op donderdag 19 juni 2008 @ 00:11:
@SchizoDuckie waarom gelijk dode HW? Als ik eventjes op Google kijk dan vind ik meer Software fouten dan HW fouten.

En ik vermoed dat het testen op HW fouten ietsjes moeilijker is dan het testen op Software fouten...

Just a hunch, noem het ervaring, noem het een wilde gok Ik kan me voorstellen dat als er tijdens dat blokje een bepaalde geheugenrange overschreen wordt waar een fout zit dat er dan een error optreedt

En dan nog, een memtest kan nooit kwaad

[ Voor 14% gewijzigd door SchizoDuckie op 19-06-2008 09:35 ]

[Voutloos]

anonimoes schreef op woensdag 18 juni 2008 @ 23:34:
Wat ik hieruit concludeer is dat er (dus) niks fundamenteel mis is met mijn code. (op schoonheidsfoutjes na)

De een noemt het een schoonheidsfoutje, ik noem het de meest slechte code style in een PHP topic van deze week. Indenting is raar, je if/else blokken en ternary operators zijn k*t uitgelijnd, je return statements zijn slecht zichtbaar en niet consequent aanwezig, je initialiseert variabelen op een wazig manier (regel 15 is echt omslachtig), etc. etc.
Persoonlijke voorkeur is ook het weglaten van de haakjes bij echo, want dat is toch geen echte functie, en je html kan ook wel wat beter.

Niet elk van deze stijl opmerkingen zal 100% ontopic zijn, maar dan moet je maar zorgen voor een kleinere testcase.

En als je dan de schuld aan de server wil geven, noem dan ook de belangrijkste zaken qua config, zoals PHP versie.

[tonyisgaaf]

anonimoes schreef op woensdag 18 juni 2008 @ 23:34:
[…]
@all: Ik heb toch eerst de logs er eens op nagekeken en in de apache errorlog kom ik segfaults tegen. Als ik het script aanroep in mijn browser en het loopt vast dan komt er netjes voor elke keer F5 een segfault bij te staan in de logfile... Wat ik hieruit concludeer is dat er (dus) niks fundamenteel mis is met mijn code. (op schoonheidsfoutjes na) Dit heb ik ook meteen maar geprobeerd op een andere server en daar herhaalt het probleem zich niet. Het lijkt er dus op dat de kern van het probleem bij apache / php ligt. Dat ga ik nu dus eerst maar eens verder uitzoeken.
[…]

Je hebt dus ook het php_error.log bekeken (behalve het apache log)? (Dat haal ik nl. niet uit deze opmerking.)

[mrFoce]

Het zou een bug kunnen zijn in PHP, die later gefixt is. Ik zie zo 123 niet welke versie van PHP je webserver draait. Upgrade je PHP versie is? En probeer het dan nog is.

Ik heb ongeveer eenzelfde error gehad in een ver verleden, dat werd opgelost door PHP te upgraden naar de laatste stable build.

[anonimoes]

Het systeem waar ik dit op test is een opensuse 10.2 systeem met php v.5.2.0 Ik ben momenteel een dvd aan het branden om dit systeem te upgraden naar opensuse 10.3 en hoop dat daarmee de fout verdwijnt. Een geheugenprobleem zou natuurlijk inderdaad ook nog kunnen. Toen ik dit systeem samenstelde had ik een verkeerd geheugenreepje die veel fouten gaf, deze is vervangen door een ander reepje die ik toen (bijna een jaar geleden) getest heb in de memtest van linux en daar kwamen geen fouten uit.

Wat betreft mijn code: blijkbaar heb ik meer te leren over php dan ik dacht, naar mijn idee is de indentation logisch en goed te volgen maar kennelijk heb ik daarin mijn eigen systeem aangeleerd... Wat ik in feite doe is dit: bij elke if, functie, loop etc gaat er een tab bij tenzij er maar 1 regel nodig is na het if statement. Maar goed, dit topic is niet primair bedoeld om daar op in te gaan en anders raken we wel erg offtopic, een slechte indentation zal iig nooit een segfault veroorzaken lijkt me

De logfiles van php heb ik nog niet bekeken, dat kan ik inderdaad nog doen.

[.oisyn]

Voutloos schreef op donderdag 19 juni 2008 @ 08:58:
[...]
De een noemt het een schoonheidsfoutje, ik noem het de meest slechte code style in een PHP topic van deze week. Indenting is raar, je if/else blokken en ternary operators zijn k*t uitgelijnd, je return statements zijn slecht zichtbaar en niet consequent aanwezig

Sorry hoor maar wat een onzin. Dat hij niet aan jou stijl voldoet wil nog niet zeggen dat het meteen slecht is (let wel, ik beperk me hier tot het gequote deel)

[Voutloos]

offtopic:
Maak er maar 'imo minst mooie' code style van, als die zaken niet per se objectief gezien slecht zijn. Ik denk toch echt dat deze manier van schrijven foutgevoeliger is en slechter te lezen en te debuggen. Maar goed, met dit soort tips valt in PHP topics geen eer te behalen, dus ik bespaar me voortaan wel de moeite van het lezen (en mogelijk meehelpen aan de oplossing) zodra ik zie dat iets naadje opschreven is.

[anonimoes]

De update naar opensuse 10.3 is net klaar en het probleem is weg! Net voordat ik de update ging doen heb ik php.ini nog even zo ingesteld dat errors ook gelogd worden maar in dit log verscheen niets over m.b.t. de segfaults. Ik ben iig erg blij dat ik nu weer verder kan coden en ik wil eenieder die meegedacht heeft dan ook hartelijk bedanken! Het wegwerken van alle notices gisteren was dan wel niet de oplossing voor het probleem maar heeft me wel laten zien dat ik best wat netter mag programmeren.

@Gomez12: je hebt het erover dat ik een kort stukje code in moet leveren bij de makers van php... Aangezien de fout voor mij al onduidelijk is en vermoedelijk in samenspel met mijn systeem ontstond lijkt het me erg lastig om een kort stukje code te maken wat deze fout herhaalt. Bovendien hebben ze het bij de begreport van php.net erover dat dingen als ZEND e.d. uitgeschakeld dienen te zijn voordat een report gemaakt wordt. Nu weet ik dat opensuse iets met zend doet maar hoe ik dit uitschakel weet ik helaas niet...

[SchizoDuckie]

Als je probleem over is na een upgrade zou ik niet eens de moeite nemen om een bugreport te doen. Ze hebben de fout klaarblijkelijk namelijk allang opgelost en dan kunnen ze zich bezig houden met andere problemen