Hvordan feilsøke PHP-skript?

stemmer
405

Hvordan feilsøke PHP -skript?

Jeg er klar over grunnleggende feilsøking for eksempel ved hjelp av feilrapportering. Stoppunkt debugging i PHPEclipse er også ganske nyttig.

Hva er den beste (i form av rask og enkel) måte å feilsøke i phpStorm eller andre IDE?

Publisert på 03/08/2008 klokken 23:18
kilden bruker
På andre språk...                            


30 svar

stemmer
145

Prøv Eclipse PDT å sette opp en Eclipse miljø som har debugging funksjoner som du nevnte. Muligheten til å gå inn i koden er en mye bedre måte å feilsøke da den gamle metoden for var_dump og skrive på ulike steder for å se hvor strømmen går galt. Når alt annet svikter selv og alt jeg har er SSH og vim jeg fortsatt var_dump()/ die()å finne hvor koden går sørover.

Svarte 03/08/2008 kl. 23:28
kilden bruker

stemmer
80

Du kan bruke Firephp en add-on til Firebug å feilsøke php i samme miljø som javascript.

Jeg bruker også Xdebug nevnt tidligere for profilering php.

Svarte 05/08/2008 kl. 17:22
kilden bruker

stemmer
38

Dette er min lille debug miljø:

error_reporting(-1);
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_BAIL, 0);
assert_options(ASSERT_QUIET_EVAL, 0);
assert_options(ASSERT_CALLBACK, 'assert_callcack');
set_error_handler('error_handler');
set_exception_handler('exception_handler');
register_shutdown_function('shutdown_handler');

function assert_callcack($file, $line, $message) {
    throw new Customizable_Exception($message, null, $file, $line);
}

function error_handler($errno, $error, $file, $line, $vars) {
    if ($errno === 0 || ($errno & error_reporting()) === 0) {
        return;
    }

    throw new Customizable_Exception($error, $errno, $file, $line);
}

function exception_handler(Exception $e) {
    // Do what ever!
    echo '<pre>', print_r($e, true), '</pre>';
    exit;
}

function shutdown_handler() {
    try {
        if (null !== $error = error_get_last()) {
            throw new Customizable_Exception($error['message'], $error['type'], $error['file'], $error['line']);
        }
    } catch (Exception $e) {
        exception_handler($e);
    }
}

class Customizable_Exception extends Exception {
    public function __construct($message = null, $code = null, $file = null, $line = null) {
        if ($code === null) {
            parent::__construct($message);
        } else {
            parent::__construct($message, $code);
        }
        if ($file !== null) {
            $this->file = $file;
        }
        if ($line !== null) {
            $this->line = $line;
        }
    }
}
Svarte 29/06/2009 kl. 13:40
kilden bruker

stemmer
32

Xdebug og DBGp plugin for Notepad ++ for heavy duty bug jakt, FirePHP for lette ting. Rask og skitne? Ingenting slår dBug .

Svarte 15/09/2008 kl. 20:23
kilden bruker

stemmer
26

XDebug er avgjørende for utvikling. Jeg installere det før alle andre filtyper. Det gir deg stable spor på eventuelle feil, og du kan aktivere profilering enkelt.

For en rask titt på en datastruktur bruk var_dump(). Bruk ikke print_r()fordi du må omgi den med <pre>, og det er skrevet ut bare ett Var gangen.

<?php var_dump(__FILE__, __LINE__, $_REQUEST); ?>

For en ekte debugging miljø det beste jeg har funnet er Komodo IDE , men det koster $$.

Svarte 22/08/2008 kl. 15:43
kilden bruker

stemmer
19

PhpED er veldig bra. Du kan gå inn i / over / ut av funksjoner. Du kan kjøre ad-hoc-kode, inspisere variabler, endre variabler. Det er utrolig.

Svarte 05/02/2009 kl. 09:16
kilden bruker

stemmer
17

1) I bruk print_r (). I Textmate, jeg har et tekstutdrag for 'pre' som utvider til dette:

echo "<pre>";
print_r();
echo "</pre>";

2) Jeg bruker Xdebug, men har ikke vært i stand til å få GUI til å fungere riktig på min Mac. Det i det minste skriver ut en lesbar versjon av stabelen spor.

Svarte 07/08/2008 kl. 00:25
kilden bruker

stemmer
16

I all ærlighet, til en kombinasjon av trykk og print_r () skrive ut variablene. Jeg vet at mange foretrekker å bruke andre mer avanserte metoder, men jeg synes dette er den enkleste å bruke.

Jeg vil si at jeg ikke fullt ut forstår dette før jeg gjorde noen mikroprosessor programmering ved Uni og var ikke i stand til å bruke selv dette.

Svarte 04/08/2008 kl. 21:28
kilden bruker

stemmer
16

Jeg har brukt Zend Studio (5,5) , sammen med Zend Platform . Det gir riktig debugging, breakpoints / tråkke over koden etc., men til en pris.

Svarte 03/08/2008 kl. 23:20
kilden bruker

stemmer
14

Xdebug ved Derick Rethans, er veldig bra. Jeg brukte den for en tid siden og fant det ikke var så lett å installere. Når du er ferdig, vil du ikke forstå hvordan du klarte deg uten :-)

Det er en god artikkel om Zend Developer Zone (installasjon på Linux virker ikke enklere) og enda en Firefox plugin , som jeg aldri har brukt.

Svarte 04/08/2008 kl. 21:07
kilden bruker

stemmer
11

Jeg bruker NetBeans med XDebug og Easy XDebug Firefox-tillegg

Tillegget er viktig når du feilsøke MVC prosjekter, fordi vanlig måte XDebug kjører i NetBeans er å registrere dbug sesjon via nettadressen. Med tillegget installert i Firefox, ville du angi NetBeans prosjektegenskaper -> Kjør Configuratuion -> Avansert og velg "Må ikke åpnes Web Browser" Du kan nå sette dine break poeng og starte debugging økt med Ctrl-F5 som vanlig . Åpne Firefox og høyreklikk tillegget på ikonet nederst i høyre hjørne for å starte overvåking for stoppunkter. Når koden når stoppunkt vil den stoppe, og du kan inspisere variable tilstander og ringe-stack.

Svarte 09/07/2010 kl. 03:14
kilden bruker

stemmer
11

Jeg bruker NetBeans med XDebug. Sjekk det ut på sin hjemmeside for dokumenter på hvordan du konfigurerer den. http://php.netbeans.org/

Svarte 26/08/2008 kl. 15:04
kilden bruker

stemmer
10

Output buffering er svært nyttig hvis du ikke ønsker å rote opp din utgang. Jeg gjør dette i en one-liner som jeg kan kommentere / uncomment på vilje

 ob_start();var_dump(); user_error(ob_get_contents()); ob_get_clean();
Svarte 22/10/2008 kl. 09:16
kilden bruker

stemmer
9

PhpEdit har en innebygget i feilsøkingsprogram, men jeg ender vanligvis opp ved hjelp av ekko (); og print_r (); den gammeldagse måten !!

Svarte 17/09/2008 kl. 10:14
kilden bruker

stemmer
8

For de virkelig sandete problemer som ville være for tidkrevende å bruke print_r / ekko å finne ut jeg bruke IDE (PhpED) debugging funksjonen. I motsetning til andre IDE jeg har brukt, krever PhpED stort sett ingen oppsett. den eneste grunnen til at jeg ikke bruker det for noen problemer jeg møter er at det er smertelig sakte. Jeg er ikke sikker på at treghet er spesifikke for PhpED eller noen php debugger. PhpED er ikke gratis, men jeg tror det bruker en av open-source debuggers (som XDebug tidligere nevnt) uansett. Fordelen med PhpED, igjen, er at det krever ingen installasjon som jeg har funnet egentlig ganske kjedelig i det siste.

Svarte 22/08/2008 kl. 15:33
kilden bruker

stemmer
4

Manuell debugging er generelt raskere for meg - var_dump()og debug_print_backtrace()er alle verktøyene du trenger for å arm din logikk med.

Svarte 22/08/2008 kl. 15:36
kilden bruker

stemmer
3

Jeg bruker ofte CakePHP når Rails er ikke mulig. Å feilsøke feil jeg vanligvis finner error.logi tmp mappen og hale det i terminalen med kommandoen ...

tail -f app/tmp/logs/error.log

Det gir oss du kjører dialog fra kake av hva som skjer, noe som er ganske hendig, hvis du ønsker å sende ut noe til det mid-kode du kan bruke.

$this->log('xxxx');

Dette kan vanligvis gi deg en god ide om hva som skjer / galt.

Svarte 10/05/2010 kl. 09:29
kilden bruker

stemmer
3

Vel, til en viss grad det avhenger av hvor ting går sørover. Det er det første jeg prøver å isolere, og så skal jeg bruke echo / print_r () etter behov.

NB: Dere vet at du kan passere sant som andre argument til print_r (), og det vil returnere utgang i stedet for å skrive det? Eg:

echo "<pre>".print_r($var, true)."</pre>";
Svarte 18/09/2008 kl. 03:17
kilden bruker

stemmer
2

Det er mange PHP debugging teknikker som kan spare deg for utallige timer når koding. En effektiv men grunnleggende feilsøking teknikk er å bare slå på feilrapportering. En annen litt mer avansert teknikk innebærer å bruke utskrifts uttalelser, som kan hjelpe finne mer unnvikende feil ved å vise hva som faktisk skjer på skjermen. PHPeclipse er et Eclipse plug-in som kan markere vanlige syntaksfeil og kan brukes i forbindelse med et feilsøkingsprogram for å angi stoppunkt.

display_errors = Off
error_reporting = E_ALL 
display_errors = On

og også brukt

error_log();
console_log();
Svarte 01/10/2015 kl. 11:16
kilden bruker

stemmer
2

NuSphere er også en god debugger for php NuSphere

Svarte 29/05/2012 kl. 12:43
kilden bruker

stemmer
2

Komodo IDE fungerer godt med xdebug, selv for remore feilsøking. Det må minimum av konfigurasjon. Alt du trenger er en versjon av php som Komodo kan bruke lokalt for å gå gjennom koden på et stoppunkt. Hvis du har skriptet importert til komodo prosjekt, så kan du sette stoppunkter med et museklikk hvor du ville sette den i eclipse for debugging et java-program. Ekstern feilsøking er åpenbart mer vanskelig å få det til å fungere riktig (du må kanskje kartlegge ekstern url med et php skript på arbeidsstedet) enn en lokal debugging oppsett som er ganske lett å konfigurere hvis du er på en Mac eller en linux desktop .

Svarte 22/08/2008 kl. 15:44
kilden bruker

stemmer
2

print_r (debug_backtrace ());

eller noe sånt :-)

Svarte 03/08/2008 kl. 23:32
kilden bruker

stemmer
1

PHP DBG

Interaktiv Stepthrough PHP Debugger implementert som en SAPI modul som kan gi gi deg full kontroll over miljøet uten at det påvirker funksjonaliteten eller ytelsen til koden din. Det skal være en lett, kraftig, enkel å bruke debugging plattform for PHP 5.4+, og det er sendt ut-av-boksen med PHP 5.6.

Funksjoner inkluderer:

  • Stepthrough Debugging
  • Fleksible stoppunkter (klasse metode, funksjon, File: Line, Adresse, Opcode)
  • Enkel tilgang til PHP med innebygd eval ()
  • Enkel tilgang til tiden kjøre kode
  • Userland API
  • SAPI Agnostic - Lett Integrert
  • PHP konfigurasjonsfil Support
  • JIT Super Globals - Sett din egen !!
  • Valgfritt readline Support - Komfortabel Terminal Drift
  • Remote Debugging Support - Medfølgende Java GUI
  • enkel betjening

Se skjermbilder:

PHP DBG - Stepthrough Debugging - skjermbilde

PHP DBG - Stepthrough Debugging - skjermbilde

Hjemmeside: http://phpdbg.com/

PHP Feil - Bedre feilrapportering for PHP

Dette er veldig enkelt å bruke biblioteket (egentlig en fil) for å feilsøke PHP-skript.

Det eneste du trenger å gjøre er å inkludere en fil som nedenfor (i begynnelsen på koden din):

require('php_error.php');
\php_error\reportErrors();

Da alle feil vil gi deg info som sporbarhet, kode sammenheng funksjonsargumenter, server variabler, etc. For eksempel:

PHP Feil |  Forbedre Feilrapportering for PHP - skjermbilde av sporbarhet PHP Feil |  Forbedre Feilrapportering for PHP - skjermbilde av sporbarhet PHP Feil |  Forbedre Feilrapportering for PHP - skjermbilde av sporbarhet

Funksjoner inkluderer:

  • trivielt å bruke, det er bare en fil
  • feilene som vises i nettleseren for normal og ajaxy forespørsler
  • AJAX forespørsler er satt på pause, slik at du automatisk å kjøre dem
  • gjør feil så strengt som mulig (oppmuntrer kodekvalitet, og har en tendens til å forbedre ytelsen)
  • kodebiter på tvers av hele stabel spor
  • gir mer informasjon (for eksempel full funksjon signaturer)
  • fikser noen feilmeldinger som er rett og slett galt
  • syntax highlighting
  • ser pen!
  • tilpasning
  • manuelt slå den av og på
  • kjøre bestemte deler uten feilrapportering
  • ignorere filer slik at du kan unngå å markere koden i stabel spor
  • programfiler; disse er prioritert når en feil inntreffer!

Hjemmeside: http://phperror.net/

GitHub: https://github.com/JosephLenton/PHP-Error

Min gaffel (med ekstra rettelser): https://github.com/kenorb-contrib/PHP-Error

DTrace

Hvis systemet støtter DTrace dynamisk sporing (installert som standard på OS X) og PHP er kompilert med DTrace sonder aktivert ( --enable-dtrace) som skal være standard, kan denne kommandoen hjelpe deg å feilsøke PHP-script uten tid:

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

Så gitt følgende alias har blitt lagt inn i rc -filer (for eksempel ~/.bashrc, ~/.bash_aliases):

alias trace-php='sudo dtrace -qn "php*:::function-entry { printf(\"%Y: PHP function-entry:\t%s%s%s() in %s:%d\n\", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }"'

du kan spore skriptet med lett å huske alias: trace-php.

Her er mer avansert DTrace script, bare lagre den i dtruss-php.d, gjør det kjørbar ( chmod +x dtruss-php.d) og kjør:

#!/usr/sbin/dtrace -Zs
# See: https://github.com/kenorb/dtruss-lamp/blob/master/dtruss-php.d

#pragma D option quiet

php*:::compile-file-entry
{
    printf("%Y: PHP compile-file-entry:\t%s (%s)\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1));
}

php*:::compile-file-return
{
    printf("%Y: PHP compile-file-return:\t%s (%s)\n", walltimestamp, basename(copyinstr(arg0)), basename(copyinstr(arg1)));
}

php*:::error
{
    printf("%Y: PHP error message:\t%s in %s:%d\n", walltimestamp, copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);
}

php*:::exception-caught
{
    printf("%Y: PHP exception-caught:\t%s\n", walltimestamp, copyinstr(arg0));
}

php*:::exception-thrown
{
    printf("%Y: PHP exception-thrown:\t%s\n", walltimestamp, copyinstr(arg0));
}

php*:::execute-entry
{
    printf("%Y: PHP execute-entry:\t%s:%d\n", walltimestamp, basename(copyinstr(arg0)), (int)arg1);
}

php*:::execute-return
{
    printf("%Y: PHP execute-return:\t%s:%d\n", walltimestamp, basename(copyinstr(arg0)), (int)arg1);
}

php*:::function-entry
{
    printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);
}

php*:::function-return
{
    printf("%Y: PHP function-return:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);
}

php*:::request-shutdown
{
    printf("%Y: PHP request-shutdown:\t%s at %s via %s\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1), copyinstr(arg2));
}

php*:::request-startup
{
    printf("%Y, PHP request-startup:\t%s at %s via %s\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1), copyinstr(arg2));
}

Hjemmeside: dtruss-lampe på GitHub

Her er enkel bruk:

  1. Kjør: sudo dtruss-php.d.
  2. På en annen terminal kjøre: php -r "phpinfo();".

For å teste det, kan du gå til noen dokumentroten med index.phpog kjøre PHP innebygde serveren ved å:

php -S localhost:8080

Etter det kan du få tilgang til området på http: // localhost: 8080 / (eller velge hva port er praktisk for deg). Derfra tilgang til enkelte sider for å se spor utgang.

Merk: DTrace er tilgjengelig på OS X som standard, på Linux trenger du sannsynligvis dtrace4linux eller se etter noen andre alternativer .

Se: Bruke PHP og DTrace på php.net


SystemTap

Alternativt kan se etter SystemTap sporing ved å installere SystemTap SDT utvikling pakke (for eksempel yum install systemtap-sdt-devel).

Her er eksempel script ( all_probes.stp) for å spore alle kjerne PHP statisk probe punkter gjennom varigheten av en kjører PHP-script med SystemTap:

probe process("sapi/cli/php").provider("php").mark("compile__file__entry") {
    printf("Probe compile__file__entry\n");
    printf("  compile_file %s\n", user_string($arg1));
    printf("  compile_file_translated %s\n", user_string($arg2));
}
probe process("sapi/cli/php").provider("php").mark("compile__file__return") {
    printf("Probe compile__file__return\n");
    printf("  compile_file %s\n", user_string($arg1));
    printf("  compile_file_translated %s\n", user_string($arg2));
}
probe process("sapi/cli/php").provider("php").mark("error") {
    printf("Probe error\n");
    printf("  errormsg %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
}
probe process("sapi/cli/php").provider("php").mark("exception__caught") {
    printf("Probe exception__caught\n");
    printf("  classname %s\n", user_string($arg1));
}
probe process("sapi/cli/php").provider("php").mark("exception__thrown") {
    printf("Probe exception__thrown\n");
    printf("  classname %s\n", user_string($arg1));
}
probe process("sapi/cli/php").provider("php").mark("execute__entry") {
    printf("Probe execute__entry\n");
    printf("  request_file %s\n", user_string($arg1));
    printf("  lineno %d\n", $arg2);
}
probe process("sapi/cli/php").provider("php").mark("execute__return") {
    printf("Probe execute__return\n");
    printf("  request_file %s\n", user_string($arg1));
    printf("  lineno %d\n", $arg2);
}
probe process("sapi/cli/php").provider("php").mark("function__entry") {
    printf("Probe function__entry\n");
    printf("  function_name %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
    printf("  classname %s\n", user_string($arg4));
    printf("  scope %s\n", user_string($arg5));
}
probe process("sapi/cli/php").provider("php").mark("function__return") {
    printf("Probe function__return: %s\n", user_string($arg1));
    printf(" function_name %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
    printf("  classname %s\n", user_string($arg4));
    printf("  scope %s\n", user_string($arg5));
}
probe process("sapi/cli/php").provider("php").mark("request__shutdown") {
    printf("Probe request__shutdown\n");
    printf("  file %s\n", user_string($arg1));
    printf("  request_uri %s\n", user_string($arg2));
    printf("  request_method %s\n", user_string($arg3));
}
probe process("sapi/cli/php").provider("php").mark("request__startup") {
    printf("Probe request__startup\n");
    printf("  file %s\n", user_string($arg1));
    printf("  request_uri %s\n", user_string($arg2));
    printf("  request_method %s\n", user_string($arg3));
}

bruk:

stap -c 'sapi/cli/php test.php' all_probes.stp

Se: Bruk av SystemTap med PHP DTrace Statiske prober på php.net

Svarte 21/03/2016 kl. 12:34
kilden bruker

stemmer
1

De fleste av feilene kan lett finnes ved ganske enkelt var_dumping noen av nøkkelvariabler, men det avhenger selvsagt av hva slags program du utvikle.

For en mer komplekse algoritmer trinnet / stoppunkt / klokkefunksjoner er svært nyttig (om ikke nødvendig)

Svarte 10/05/2010 kl. 09:18
kilden bruker

stemmer
1

Jeg bruker Zend studio for eclipse med den innebygde debugger. Dens fortsatt treg i forhold til debugging med Eclipse PDT med xdebug. Forhåpentligvis vil de fikse disse problemene, har hastigheten økt i løpet av de siste utgivelsene, men fortsatt tråkke over ting tar 2-3 sekunder. Zend firefox verktøylinjen virkelig gjør ting enkelt (debug neste side, gjeldende side, etc). Også det gir en profiler som vil benchmark koden din og gi Pie-diagrammer, kjøretid, etc.

Svarte 17/08/2008 kl. 18:38
kilden bruker

stemmer
1

I et produksjonsmiljø, jeg logger relevante data til serverens feilloggen med error_log ().

Svarte 15/08/2008 kl. 04:23
kilden bruker

stemmer
1

1 for print_r (). Bruk den til å dumpe ut innholdet av et objekt eller variabel. For å gjøre det lettere å lese, gjør det med en pre-koden slik at du ikke trenger å vise kilden.

echo '<pre>';
print_r($arrayOrObject);

Også var_dump ($ thing) - dette er veldig nyttig å se hvilken type subthings

Svarte 05/08/2008 kl. 00:49
kilden bruker

stemmer
0

Vanligvis finner jeg lage en ny tilpasset log funksjon i stand til å lagre på fil, lagre debug info, og til slutt re-print på en felles bunntekst.

Du kan også overstyre felles Unntak klasse, slik at denne type debugging er semi-automatisert.

Svarte 22/10/2008 kl. 08:46
kilden bruker

stemmer
0

De integrerte debuggers der du kan se verdiene av variabelendringen som du går gjennom koden er virkelig kult. De gjør imidlertid kreve installering av programvare på serveren og en viss konfigurasjon på klienten. Som begge krever periodisk vedlikehold for å holde i god stand.

En print_r er lett å skrive og er garantert å fungere i alle oppsett.

Svarte 22/08/2008 kl. 20:10
kilden bruker

stemmer
0

Avhengig av problemet jeg liker en kombinasjon av error_reporting (E_ALL) blandet med ekko tester (for å finne den fornærmende linje / fil feilen skjedde i initally, du vet det er ikke alltid den linjen / fil php forteller deg rett?), IDE brace matchende (for å løse "Tolkefeil feil~~POS=HEADCOMP: syntax error, uventet $ end" utgaver), og print_r (); exit; fyllinger (reelle programmerere viser kilden; p).

Du kan også slå phpdebug (sjekk sourceforge) med "memory_get_usage ();" og "memory_get_peak_usage ();" å finne problemområdene.

Svarte 06/08/2008 kl. 15:46
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more