[PHP] Extreem nested debuggen *

[Verwijderd]

Ik heb momenteel de verplichting een aantal fouten uit een site te halen, en wat spul er bij in te bouwen. Hiervoor moet ik hem locaal hebben draaien. De site draait perfect op de server, voor zover ik weet met dezelfde versies van de daarvoor bestemde programma;s. Alleen als ik hem gedownload heb, de database heb overgezet ed, dan blijft het ding in bepaalde loopjes hang waarvan ik de herkomst niet kan traceren.

Nu is het ding een beetje heel erg rottig geprogrameerd, en bestaat het zelfs uit frames en duizenden includes in includes in includes, dus het specifieke stukje regel kan ik moeilijk aanwijzen.

Weet iemand waar dit aan zou kunnen liggen / hoe dit te verhelpen is?

[curry684]

Uhm ja, en nu denk je dat wij je kunnen helpen als je niet eens aangeeft in welke technologie het ontwikkeld is?

[Verwijderd]

curry684 schreef op dinsdag 07 december 2004 @ 16:56:
Uhm ja, en nu denk je dat wij je kunnen helpen als je niet eens aangeeft in welke technologie het ontwikkeld is?

Excusez moi, helemaal over het hoofd gezien

PHP

[whoami]

Mjah, ik denk dat er maar 1 ding opzit:
debuggen: stap voor stap door je code heenlopen, regel per regel uitvoeren en kijken waar het mis gaat.

[marko77]

Waarom kan je m niet op de server draaien in een test dir?

dat lijkt me een stuk eenvoudiger
je zegt 'voor zover ik weet met dezelfde versies' ik zou maar even uitzoeken welke versies er precies draaien, dat zal een hoop gezoek voorkomen

[RM-rf]

Verwijderd schreef op dinsdag 07 december 2004 @ 16:55:

dus het specifieke stukje regel kan ik moeilijk aanwijzen.

PHP geeft toch de regel en bestandsnaam waarin de fout is opgetreden terug?
Wat is dan de foutmelding?

[NMe]

Gewoon op strategische/verdachte punten debuginfo outputten, veel meer zit er niet op.

[MisterData]

Misschien is het wel gewoon een instelling, zoals bijvoorbeeld het maximale geheugengebruik of de maximale tijd die een script mag draaien... dan kan 'ie overal in het script ermee ophouden als 'ie over z'n limiet komt.... controleer dat eerst even dus

[Verwijderd]

Gebruik ook een van de vele beschikbare debuggers voor php, die kunnen je misschien helpen

[Verwijderd]

RM-rf schreef op dinsdag 07 december 2004 @ 17:04:
[...]

PHP geeft toch de regel en bestandsnaam waarin de fout is opgetreden terug?
Wat is dan de foutmelding?

Er is geen foutmelding. Wel een eeuwig loopje waarin het gebeuren gaat verkeren, hier locaal.

[Verwijderd]

Ik doe nog maar een debug-poging. Ik laat het weten als het me lukt.

[Verwijderd]

Soms kan een netwerksniffer (zoals ethereal) ook wel verduidelijken wat er precies gebeurt.

[Yo-han]

Verwijderd schreef op woensdag 08 december 2004 @ 08:48:
[...]


Er is geen foutmelding. Wel een eeuwig loopje waarin het gebeuren gaat verkeren, hier locaal.

Mischien een domme opmerking maar misschien ook niet.

Ik zag dat je de omgeving net lokaal geinstalleerd had, mar heb jer ook aan gedacht om "display_errors" in je php.ini op ON te zetten?? Ik heb hier ervaring mee (tja...)
Verder zou ik even ERROR_REPORTING op E_ALL zetten.

[4Real]

Laat het stukje code van het loopje eens zien, misschien is het dan iets makkelijker met helpen

[Verwijderd]

Duizendmaal excuses, ik heb phpinfo(); even locaal en op de server vergeleken, en de site bleek gemaakt te zijn op een server met register globals aan.

Wat een slechte site is het ook joh

[Yo-han]

Hmmm, dus toch in de php.ini!!!

[Verwijderd]

Verwijderd schreef op woensdag 08 december 2004 @ 12:03:
Duizendmaal excuses, ik heb phpinfo(); even locaal en op de server vergeleken, en de site bleek gemaakt te zijn op een server met register globals aan.

Wat een slechte site is het ook joh

Dat de server werkt met register_globals on, hoeft niet te betekenen dat je slecht programmeert. Je kan namelijk nog steeds superglobals gebruiken. Het lokt alleen ranzigheid uit. Ik denk ook dat je snel aan de code had kunnen zien dat de orginele maker niet met superglobals werkt(e).
Het omzetten kan een aardige klus zijn, maar je kan ook gewoon bovenaan alle $_GET en $_POST variabelen global maken. Zo bied je het script alsnog de mogelijkheid om in register_globals on te werken, sort of...
Succes!

[flashin]

Of gewoon via .htaccess:

Please note that register_globals cannot be set at runtime (ini_set()). Although, you can use .htaccess if your host allows it as described above. An example .htaccess entry: php_flag register_globals on.

[NMe]

Wanneer dit script toch snel moet draaien zonder register_globals op on te zetten, kun je eventueel dit gebruiken bovenaan je pagina:

PHP:

extract($_REQUEST);

Op die manier kun je met variabelen werken als waren het globals. Uiteraard is dit even goed beveiligd als een server met register_globals op on, wat dus betekent dat je de code zo snel mogelijk hoort te verbeteren. Intussen kun je de site wel online gooien.