[PHP 5.3.11] [Apache 2.22] Upgrade breekt token_get_all

[Firesphere]

Vannacht heeft 1 van onze partner-bedrijven hun servers geupgrade naar Apache 2.22 met PHP 5.3.11, sindsdien geeft

PHP:

token_get_all("<?php string('substring,substring,substring')");

Een null terug in plaats van de verwachte array met open/string/substring types.

Is er iemand hier die daar toevallig meer over weet, zowel ikzelf als de hoster heeft er eigenlijk geen verklaring voor.

[CodeCaster]

Works for me (PHP 5.3.5).

Ergens daartussen hebben ze vermoedelijk dus wat gesloopt (welke versie draaide je voorheen?), dus kun je een bugreport indienen.

[Firesphere]

Nou ja, ik zelf heb er niet veel invloed op, en heb ook (nog) geen idee waar het aan ligt.

Daarnaast zijn ze inderdaad al bij 5.3.5, en snap ik ook niet waarom de hostingpartij heeft gekozen voor 5.3.11 (5.3.12 is de CGI-bugfix versie!)

Het vreemde is, ik kan er niets over terug vinden, blijkbaar is er toch iets stuk, maar wat? Zou het de installatie zijn, of toch PHP zelf?
Het is gewoon een vreemde situatie, token_get_all (sowieso de tokenizer) is nou niet iets waar tegenwoordig zo heel veel core-werk aan wordt verricht, hoogstens enkele bugfixes, maar die kan ik niet vinden tussen 5.3.10 en 5.3.2 eigenlijk.

Sowieso weet ik dat 5.3.10 wel gewoon werkt. Aangezien onze eigen site daar onder draait.

[RobIII]

Ik zie hier iig weinig spannends staan dat er mee te maken heeft.

5.3.6 en 5.4.1 geven:

code:

array(5) {
  [0]=>
  array(3) {
    [0]=>
    int(372)
    [1]=>
    string(6) "
    int(1)
  }
  [1]=>
  array(3) {
    [0]=>
    int(307)
    [1]=>
    string(6) "string"
    [2]=>
    int(1)
  }
  [2]=>
  string(1) "("
  [3]=>
  array(3) {
    [0]=>
    int(315)
    [1]=>
    string(31) "'substring,substring,substring'"
    [2]=>
    int(1)
  }
  [4]=>
  string(1) ")"
}

[Osiris]

Hmm, mijn CLI-versie van 5.3.10 doet 't echter niet hoor. Mijn 5.3.10 doet 't toch

[ Voor 22% gewijzigd door Osiris op 10-05-2012 18:19 ]

[NMe]

Wat gebeurt er als je die string netjes afsluit met een ?>?

[ Voor 3% gewijzigd door NMe op 10-05-2012 18:17 ]

[Firesphere]

NMe schreef op donderdag 10 mei 2012 @ 18:17:
Wat gebeurt er als je die string netjes afsluit met een ?>?

code:

[User Error] Uncaught ReflectionException: Class null does not exist

Dat krijg ik dus op elke mogelijke poging terug. Helaas. Ik kan er echt niets zinnigs over zeggen, heb alles geprobeerd. En de "null-returns" escapen levert nog grotere fouten op.

[ Voor 25% gewijzigd door Firesphere op 10-05-2012 18:23 ]

[Gtoniser]

Firesphere schreef op donderdag 10 mei 2012 @ 18:13:
Nou ja, ik zelf heb er niet veel invloed op, en heb ook (nog) geen idee waar het aan ligt.

Daarnaast zijn ze inderdaad al bij 5.3.5, en snap ik ook niet waarom de hostingpartij heeft gekozen voor 5.3.11 (5.3.12 is de CGI-bugfix versie!)

Het vreemde is, ik kan er niets over terug vinden, blijkbaar is er toch iets stuk, maar wat? Zou het de installatie zijn, of toch PHP zelf?
Het is gewoon een vreemde situatie, token_get_all (sowieso de tokenizer) is nou niet iets waar tegenwoordig zo heel veel core-werk aan wordt verricht, hoogstens enkele bugfixes, maar die kan ik niet vinden tussen 5.3.10 en 5.3.2 eigenlijk.

Sowieso weet ik dat 5.3.10 wel gewoon werkt. Aangezien onze eigen site daar onder draait.

Je realiseert je wel dat 5.3.5 ouder is dan 5.3.10?
Vermoedelijk niet heel relevant voor het probleem maar je haalt wel wat dingen door elkaar

[Firesphere]

Gtoniser schreef op donderdag 10 mei 2012 @ 18:23:
[...]

Je realiseert je wel dat 5.3.5 ouder is dan 5.3.10?
Vermoedelijk niet heel relevant voor het probleem maar je haalt wel wat dingen door elkaar

Ehh, jep, ik heb inderdaad 5.3.2 gezien als 5.3.20, my bad.

Hoewel 5.4 ook al bestaat

[NMe]

5.3 wordt nog apart onderhouden naast 5.4 volgens mij.

Wat is die "string"-call eigenlijk? Is dat wel netjes een bestaande functie (met een ongelukkige naam)? Ik heb het idee dat PHP ergens bokt op je code in die string. weet je zeker dat die wel werkt zonder die token_get_all-call?

[RobIII]

NMe schreef op donderdag 10 mei 2012 @ 18:29:
5.3 wordt nog apart onderhouden naast 5.4 volgens mij.

[ Voor 5% gewijzigd door RobIII op 10-05-2012 18:37 ]

[Firesphere]

NMe schreef op donderdag 10 mei 2012 @ 18:29:
5.3 wordt nog apart onderhouden naast 5.4 volgens mij.

Wat is die "string"-call eigenlijk? Is dat wel netjes een bestaande functie (met een ongelukkige naam)? Ik heb het idee dat PHP ergens bokt op je code in die string. weet je zeker dat die wel werkt zonder die token_get_all-call?

Nee, het is een geldige code, in andere versies geeft het een correcte respons.

De letterlijke call is:

PHP:

token_get_all("<?php SearchExtension('Title,Description');");

Is gewoon correct en heeft ook altijd gewerkt. Zie ook RobIII in "[PHP 5.3.11] [Apache 2.22] Upgrade breekt token_get_all" waar hij de respons heeft gecopypasted. (Zag er zelf niet echt de toegevoegde waarde van, vandaar dat ik't achterwege liet, RobIII z'n reactie geeft aan dat't wel gewoon een legal call is).

(Het is trouwens een manifest/database builder die de call doet, vanuit een framework, heb de mensen achter SilverStripe ook al gemaild )

En inderdaad, 5.3 en 5.4 worden naast elkaar onderhouden, I knew that much

[ Voor 15% gewijzigd door Firesphere op 10-05-2012 18:45 ]

[RobIII]

NMe schreef op donderdag 10 mei 2012 @ 18:29:
Is dat wel netjes een bestaande functie (met een ongelukkige naam)? Ik heb het idee dat PHP ergens bokt op je code in die string. weet je zeker dat die wel werkt zonder die token_get_all-call?

Firesphere schreef op donderdag 10 mei 2012 @ 18:41:
Is gewoon correct en heeft ook altijd gewerkt. Zie ook RobIII in "[PHP 5.3.11] [Apache 2.22] Upgrade breekt token_get_all" waar hij de respons heeft gecopypasted. (Zag er zelf niet echt de toegevoegde waarde van, vandaar dat ik't achterwege liet, RobIII z'n reactie geeft aan dat't wel gewoon een legal call is).

Sterker: Ik mag hopen dat een tokenizer niet eerst code gaat uitvoeren (parsen/controleren/whatever) voordat 'ie z'n werk doet Vandaar dat ik "blind" de "ongeldige code" copy/paste in mijn test; dat moet immers net zo goed werken als wél valide functies.

[ Voor 19% gewijzigd door RobIII op 10-05-2012 19:02 ]

[Firesphere]

Dat dus... als de respons ongeldig zou zijn, zou het niet moeten breken op de tokenizer. Een tokenizer doet gewoon "ow string, nou, hier zijn de tokens van die string, succes", niet "dit wil ik niet hoor, het is incorrect" (naast dat de token gewoon correct is trouwens )

EDIT!

Hoewel ik zelf ook heel erg vermoed dat er een bug in de 5.3.11 versie van PHP is geslopen, vraag ik mij af of Apache 2.22 hier echt niets mee te maken heeft. Aangezien er geen wijzigingen in de tokenizer zijn gedaan die significante aanleiding geven voor deze foutmelding.

Ik ben zelf niet in staat om deze setup na te bootsen helaas, als iemand het wel kan, wil ik graag het resultaat horen van verschillende Apache-versies ook.

[ Voor 44% gewijzigd door Firesphere op 10-05-2012 19:18 ]

[Cartman!]

Hebben ze niet toevallig een patch of extensie geinstalleerd die dit breekt?

Ik kan je iig. vertellen dat het op php 5.3.13 (met suhosin extensie) en apache 2.4 prima werkt.

[NMe]

RobIII schreef op donderdag 10 mei 2012 @ 18:59:
[...]

Sterker: Ik mag hopen dat een tokenizer niet eerst code gaat uitvoeren (parsen/controleren/whatever) voordat 'ie z'n werk doet Vandaar dat ik "blind" de "ongeldige code" copy/paste in mijn test; dat moet immers net zo goed werken als wél valide functies.

Ik heb PHP wel gekkere dingen zien doen:

PHP:

$var1 = '';
$var2 = $var3 = null;

$var1--;
$var2--;
$var3++;

var_dump($var1);
var_dump($var2);
var_dump($var3);

[Spider.007]

Firesphere schreef op donderdag 10 mei 2012 @ 19:02:
[...]

Hoewel ik zelf ook heel erg vermoed dat er een bug in de 5.3.11 versie van PHP is geslopen, vraag ik mij af of Apache 2.22 hier echt niets mee te maken heeft. Aangezien er geen wijzigingen in de tokenizer zijn gedaan die significante aanleiding geven voor deze foutmelding.

Ik ben zelf niet in staat om deze setup na te bootsen helaas, als iemand het wel kan, wil ik graag het resultaat horen van verschillende Apache-versies ook.

Het lijkt mij heel sterk dat Apache hier invloed op heeft. Volgens deze site werkt je voorbeeld toch echt overal :

http://3v4l.org/atYJQ

Kun je de code niet zelf, of door je hoster op de CLI (dus zonder tussenkomst van Apache) laten testen?

[Firesphere]

Spider.007 schreef op donderdag 10 mei 2012 @ 21:21:
[...]

Het lijkt mij heel sterk dat Apache hier invloed op heeft. Volgens deze site werkt je voorbeeld toch echt overal :

http://3v4l.org/atYJQ

Kun je de code niet zelf, of door je hoster op de CLI (dus zonder tussenkomst van Apache) laten testen?

Dat is nog wel een idee, dat heb ik nog niet geprobeerd. CLI toegang heb ik op die hosting niet, maar het is het proberen waard

[Firesphere]

Het is opgelost met een PHP 5.3.13 installatie.

Het "grappige" is, dat een concullega van ons, vandaag hetzelfde probleem ontdekte bij 1 van zijn sites! Er lijkt dus toch iets mis te zijn met 5.3.11.