[PHP] Error 324 response -> bug?

[bindsa]

Gisteren ben ik een paar uur bezig geweest met een probleem op te lossen, ik was bezig met het schrijven van een uitbreiding op een klasse, maar wat ik ook deed, ik kreeg elke keer een error 324 (empty response) van de server terug. Uiteindelijk ben ik erachter gekomen wat het probleem was, er zat wel eens waar een fout in mijn code, maar mijns inziens zit er ook een bug in PHP, aangezien die geen error/exception terug gaf. Met deze code is het probleem te reproduceren:

PHP:

<?php
//Tested in: 5.2.12
echo phpversion();

class foo {
    function bar() { }
}

class bar extends foo {
    function __construct() {
        $this->bar();
    }
    function bar(){
       //Should be: parent::bar();
       $this->bar();
    }
}

//This will result in an empty response error (code 324)
$test = new bar;
?>

De fout zit 'em erin dat ik $this->bar() aanroep vanuit bar() zelf, terwijl ik eigenlijk diezelfde functie van de parent class wou aanroepen, dus er zat inderdaad een fout in de code. Maar volgens mij moet PHP dan óf een geheugen error teruggeven of een timeout, of zie ik dat verkeerd? Concreet de vraag: Moet ik dit als bug reporten op php.net of niet?

[Verwijderd]

Ik krijg gewoon een "allowed memory size exhausted" fatal error (PHP 5.3.2)

[bindsa]

Verwijderd schreef op dinsdag 08 juni 2010 @ 12:56:
Ik krijg gewoon een "allowed memory size exhausted" fatal error (PHP 5.3.2)

Ok, da's interessant, blijkbaar is het opgelost met PHP 5.3 Bedankt voor je reactie, vond het al zo vreemd

[mithras]

5.2.10-2ubuntu6.4:

Maximum function nesting level of '100' reached, aborting!

Ligt dus aan jouw error reporting gok ik zo

[bindsa]

mithras schreef op dinsdag 08 juni 2010 @ 13:00:
5.2.10-2ubuntu6.4:

[...]


Ligt dus aan jouw error reporting gok ik zo

Nope, net op E_ALL gezet, zelfde probleem, bovendien, als het daar al aan zou liggen, dan zou ik toch een lege pagina krijgen i.p.v. een HTTP error?

[NMe]

L0calh0st schreef op dinsdag 08 juni 2010 @ 12:51:
De fout zit 'em erin dat ik $this->bar() aanroep vanuit bar() zelf, terwijl ik eigenlijk diezelfde functie van de parent class wou aanroepen, dus er zat inderdaad een fout in de code. Maar volgens mij moet PHP dan óf een geheugen error teruggeven of een timeout, of zie ik dat verkeerd? Concreet de vraag: Moet ik dit als bug reporten op php.net of niet?

Stack overflows genereren is sowieso niet zo goed voor je applicatie. Beetje stom als in eerdere versies van PHP geen foutmelding gegooid werd, al denk ik eerder dat het aan jouw error_reporting in combinatie met display_errors en/of friendly HTTP-messages in IE ligt.

Verder: to understand recursion you must first understand recursion. Ik zou er eens een boek bij pakken voor de verandering. Dat een functie die zichzelf onconditioneel aanroept een stack overflow veroorzaakt zou je aan je water moeten voelen.

[bindsa]

NMe schreef op dinsdag 08 juni 2010 @ 13:21:
[...]

Stack overflows genereren is sowieso niet zo goed voor je applicatie. Beetje stom als in eerdere versies van PHP geen foutmelding gegooid werd, al denk ik eerder dat het aan jouw error_reporting in combinatie met display_errors en/of friendly HTTP-messages in IE ligt.

Verder: to understand recursion you must first understand recursion. Ik zou er eens een boek bij pakken voor de verandering. Dat een functie die zichzelf onconditioneel aanroept een stack overflow veroorzaakt zou je aan je water moeten voelen.

Display_erorrs en error_reporting staan goed, daar had ik wel even naar gekeken En de browser was trouwens Chrome.

Recursie snap ik wel redelijk, ik had gisteren gewoon even vergeten dat ik de functie van de parent class wou aanroepen i.p.v. de functie van de child class. En aangezien ik geen error kreeg ben ik een mooi poosje (lees: 1,5 uur) zoet geweest met het uitzoeken waar de fout zat. Als ik een stack overflow had gekregen, dan was ik waarschijnlijk sneller klaar geweest. Ik zal de host eens even een ticket sturen om te vragen of ze geen PHP upgrade moeten doen. 5.3 voegt toch wel redelijk wat toe (o.a. de serialisatie van private en protected vars is gerepareerd, in eerdere versie waren die opeens verdwenen)

Nog even een heel ander vraagje:
Hoe werken die filters in de PW? Is het iets van base64encoded ofzo?
VB: #filter:Ncw7CsMwEIThu0ztwpiYGB0gkEKVy5DC3h2IQMkaSc6DkLtHLlzO98N8EaePrcWbEg7ltt5nNLCkTKfAqBWfga-842ipVFNmqbSkIPThAde1bYMsluinN1y_j61thZFSqONCOWuGu-Bw7OtDN-D6-wM

[Feanathiel]

L0calh0st schreef op dinsdag 08 juni 2010 @ 13:46:
Nog even een heel ander vraagje:
Hoe werken die filters in de PW? Is het iets van base64encoded ofzo?
VB: #filter:Ncw7CsMwEIThu0ztwpiYGB0gkEKVy5DC3h2IQMkaSc6DkLtHLlzO98N8EaePrcWbEg7ltt5nNLCkTKfAqBWfga-842ipVFNmqbSkIPThAde1bYMsluinN1y_j61thZFSqONCOWuGu-Bw7OtDN-D6-wM

De browser haalt de gekozen waarden van de filters op en verstuurd deze vervolgens naar de server. De server bepaald de zoekresultaten, maar maakt ook een hash van deze resultaten combinatie van filterwaarden. De resultaten worden hierbij waarschijnlijk opgeslagen in een database (cache?) om ze vervolgens sneller te kunnen serveren. Wat je dan terug krijgt is zijn de zoekresultaten met deze hash. De hash is deze 'filter' die je zelf al noemde.

Zie: http://tweakers.net/xmlht...dSpecIds[]=16&output=json

Let wel op dat het geen public api is.

[Vinnybinny]

Dat is json_encode Kan je weer decoderen met json_decode

http://www.php.net/json

Hash wordt hoogstwaarschijnlijk inderdaad vergeleken met een tabel in de database, die dan het goede resultaat teruggeeft.

[ Voor 60% gewijzigd door Vinnybinny op 07-11-2011 12:16 ]

[bindsa]

Vinnybinny schreef op dinsdag 08 juni 2010 @ 14:28:
Dat is json_encode Kan je weer decoderen met json_decode

http://www.php.net/json

Hash word hoogstwaarschijnlijk inderdaad vergeleken met een tabel in de database, die dan het goede resultaat teruggeeft.

Ah ik snap het, ik dacht eerst dat het base64 was, maar dat bleek het niet te zijn