Question

Comment déboguer PHP des scénarios ?

Je connais le débogage de base, comme l'utilisation du rapport d'erreurs.Le débogage du point d'arrêt dans PHPEclipse est également très utile.

Quel est le meilleur (en termes de moyen rapide et facile) de déboguer dans phpStorm ou tout autre IDE ?

Était-ce utile?

La solution

Essayer Éclipse PDT pour configurer un environnement Eclipse doté de fonctionnalités de débogage comme vous l'avez mentionné.La possibilité d'accéder au code est une bien meilleure façon de déboguer que l'ancienne méthode var_dump et d'imprimer à différents points pour voir où votre flux se passe mal.Quand tout le reste échoue et que tout ce que j'ai, c'est SSH et vim, je continue var_dump()/die() pour trouver où le code va vers le sud.

Autres conseils

Vous pouvez utiliser Firephp, un module complémentaire de Firebug, pour déboguer PHP dans le même environnement que Javascript.

J'utilise aussi Xdebug mentionné plus tôt pour le profilage de php.

Voici mon petit environnement de débogage :

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;
        }
    }
}

Xdebug et le plugin DBGp pour Notepad++ pour la chasse aux bogues intensive, FirePHP pour les choses légères.Rapide et sale?Rien ne bat dBogue.

XDebug est essentiel au développement.Je l'installe avant toute autre extension.Il vous donne des traces de pile sur toute erreur et vous pouvez facilement activer le profilage.

Pour un aperçu rapide d’une structure de données, utilisez var_dump().Ne pas utiliser print_r() parce que tu devras l'entourer de <pre> et il n'imprime qu'une seule variable à la fois.

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

Pour un véritable environnement de débogage, le meilleur que j'ai trouvé est L'IDE de Komodo mais ça coûte $$.

PhpEd est vraiment bien.Vous pouvez accéder/supprimer/sortir des fonctions.Vous pouvez exécuter du code ad hoc, inspecter des variables, modifier des variables.C'est étonnant.

1) J'utilise print_r().Dans TextMate, j'ai un extrait de code pour « pré » qui se développe comme suit :

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

2) J'utilise Xdebug, mais je n'ai pas réussi à faire fonctionner l'interface graphique correctement sur mon Mac.Il imprime au moins une version lisible de la trace de la pile.

J'ai utilisé le Zend Studio (5.5), ensemble avec Plateforme Zend.Cela donne un débogage approprié, des points d'arrêt/un franchissement du code, etc., bien qu'à un prix.

En toute honnêteté, une combinaison de print et print_r() pour imprimer les variables.Je sais que beaucoup préfèrent utiliser d’autres méthodes plus avancées, mais je trouve que celle-ci est la plus simple à utiliser.

Je dirai que je n'ai pas pleinement apprécié cela jusqu'à ce que je fasse de la programmation de microprocesseurs à l'Université et que je ne sois même pas capable de l'utiliser.

Xdebug, de Derick Rethans, est très bon.Je l'ai utilisé il y a quelque temps et j'ai trouvé qu'il n'était pas si simple à installer.Une fois que vous aurez terminé, vous ne comprendrez plus comment vous avez fait sans :-)

Il y a un bon article sur Zone Développeur Zend (l'installation sous Linux ne semble pas plus simple) et même un Plugin Firefox, que je n'ai jamais utilisé.

J'utilise Netbeans avec XDebug.Consultez-le sur son site Web pour obtenir de la documentation sur la façon de le configurer.http://php.netbeans.org/

J'utilise Netbeans avec XDebug et le Module complémentaire XDebug FireFox facile

Le module complémentaire est essentiel lorsque vous déboguez des projets MVC, car la manière normale dont XDebug s'exécute dans Netbeans consiste à enregistrer la session de débogage via l'URL.Avec le module complémentaire installé dans FireFox, vous devez définir les propriétés de votre projet Netbeans -> Exécuter la configuration -> Avancé et sélectionner "Ne pas ouvrir le navigateur Web". Vous pouvez maintenant définir vos points d'arrêt et démarrer la session de débogage avec Ctrl-F5 comme d'habitude .Ouvrez FireFox et cliquez avec le bouton droit sur l'icône du module complémentaire dans le coin inférieur droit pour démarrer la surveillance des points d'arrêt.Lorsque le code atteint le point d'arrêt, il s'arrêtera et vous pourrez inspecter les états de vos variables et votre pile d'appels.

La mise en mémoire tampon de sortie est très utile si vous ne voulez pas gâcher votre sortie.Je fais cela dans un one-liner que je peux commenter/décommenter à volonté

 ob_start();var_dump(); user_error(ob_get_contents()); ob_get_clean();

PhpEdit a un débogueur intégré, mais je finis généralement par utiliser echo();et print_r();à l'ancienne !!

Pour les problèmes vraiment graves qui prendraient trop de temps à utiliser print_r/echo pour comprendre, j'utilise la fonction de débogage de mon IDE (PhpEd).Contrairement aux autres IDE que j'ai utilisés, PhpEd ne nécessite pratiquement aucune configuration.la seule raison pour laquelle je ne l'utilise pas pour les problèmes que je rencontre, c'est qu'il est douloureusement lent.Je ne suis pas sûr que la lenteur soit spécifique à PhpEd ou à tout débogueur php.PhpEd n'est pas gratuit mais je pense qu'il utilise de toute façon l'un des débogueurs open source (comme XDebug mentionné précédemment).L'avantage de PhpEd, encore une fois, est qu'il ne nécessite aucune configuration, ce que j'ai trouvé vraiment fastidieux dans le passé.

Le débogage manuel est généralement plus rapide pour moi - var_dump() et debug_print_backtrace() sont tous les outils dont vous avez besoin pour armer votre logique.

Eh bien, dans une certaine mesure, cela dépend de la direction vers laquelle les choses se dirigent vers le sud.C'est la première chose que j'essaie d'isoler, puis j'utiliserai echo/print_r() si nécessaire.

Attention :Vous savez que vous pouvez passer true comme deuxième argument à print_r() et qu'il renverra la sortie au lieu de l'imprimer ?Par exemple.:

echo "<pre>".print_r($var, true)."</pre>";

J'utilise souvent CakePHP lorsque Rails n'est pas possible.Pour déboguer les erreurs, je trouve généralement le error.log dans le dossier tmp et suivez-le dans le terminal avec la commande...

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

Cela vous donne une boîte de dialogue en cours d'exécution à partir du gâteau sur ce qui se passe, ce qui est assez pratique, si vous souhaitez afficher quelque chose au milieu du code que vous pouvez utiliser.

$this->log('xxxx');

Cela peut généralement vous donner une bonne idée de ce qui se passe ou ne va pas.

print_r( debug_backtrace() );

ou quelque chose comme ça :-)

Komodo IDE fonctionne bien avec xdebug, même pour le débogage ultérieur.Il nécessite un minimum de configuration.Tout ce dont vous avez besoin est une version de PHP que Komodo peut utiliser localement pour parcourir le code sur un point d'arrêt.Si vous avez importé le script dans le projet Komodo, vous pouvez définir des points d'arrêt d'un simple clic de souris, exactement comme vous le feriez dans Eclipse pour déboguer un programme Java.Le débogage à distance est évidemment plus délicat à faire fonctionner correctement (vous devrez peut-être mapper l'URL distante avec un script php dans votre espace de travail) qu'une configuration de débogage local qui est assez facile à configurer si vous êtes sur un ordinateur MAC ou Linux. .

Nusphere est également un bon débogueur pour phpnusphère

Il existe de nombreuses techniques de débogage PHP qui peuvent vous faire gagner d’innombrables heures lors du codage.Une technique de débogage efficace mais basique consiste simplement à activer le rapport d’erreurs.Une autre technique légèrement plus avancée consiste à utiliser des instructions print, qui peuvent aider à identifier des bogues plus insaisissables en affichant ce qui se passe réellement à l'écran.PHPeclipse est un plug-in Eclipse qui peut mettre en évidence les erreurs de syntaxe courantes et peut être utilisé conjointement avec un débogueur pour définir des points d'arrêt.

display_errors = Off
error_reporting = E_ALL 
display_errors = On

et également utilisé

error_log();
console_log();

Dans un environnement de production, j'enregistre les données pertinentes dans le journal des erreurs du serveur avec error_log().

J'utilise Zend Studio pour Eclipse avec le débogueur intégré.C'est toujours lent par rapport au débogage avec Eclipse PDT avec xdebug.Espérons qu'ils résoudront ces problèmes, la vitesse s'est améliorée par rapport aux versions récentes, mais il faut quand même 2 à 3 secondes pour franchir les étapes.La barre d'outils Zend Firefox facilite vraiment les choses (débogage de la page suivante, de la page actuelle, etc.).Il fournit également un profileur qui comparera votre code et fournira des diagrammes circulaires, le temps d'exécution, etc.

La plupart des bugs peuvent être trouvés facilement simplement en var_dumpIl s'agit de certaines variables clés, mais cela dépend évidemment du type d'application que vous développez.

Pour des algorithmes plus complexes, les fonctions step/breakpoint/watch sont très utiles (si elles ne sont pas nécessaires)

PHP DBG

Le débogueur PHP interactif pas à pas implémenté en tant que module SAPI qui peut vous donner un contrôle complet sur l'environnement sans affecter la fonctionnalité ou les performances de votre code.Il vise à être une plate-forme de débogage légère, puissante et facile à utiliser pour PHP 5.4+ et est livré prêt à l'emploi avec PHP 5.6.

Les fonctionnalités incluent :

  • Débogage pas à pas
  • Points d'arrêt flexibles (méthode de classe, fonction, fichier : ligne, adresse, opcode)
  • Accès facile à PHP avec eval() intégré
  • Accès facile au code en cours d'exécution
  • API de l'espace utilisateur
  • SAPI Agnostique - Facilement intégré
  • Prise en charge des fichiers de configuration PHP
  • JIT Super Globals - Définissez le vôtre !!
  • Prise en charge de readline en option - Fonctionnement confortable du terminal
  • Prise en charge du débogage à distance - Interface graphique Java fournie
  • Opération facile

Voir les captures d'écran :

PHP DBG - Stepthrough Debugging - screenshot

PHP DBG - Stepthrough Debugging - screenshot

Page d'accueil : http://phpdbg.com/

Erreur PHP - Meilleur rapport d'erreurs pour PHP

Il s'agit d'une bibliothèque très simple à utiliser (en fait un fichier) pour déboguer vos scripts PHP.

La seule chose que vous devez faire est d'inclure un fichier comme ci-dessous (au début de votre code) :

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

Ensuite, toutes les erreurs vous donneront des informations telles que la trace, le contexte du code, les arguments de fonction, les variables du serveur, etc.Par exemple:

PHP Error | Improve Error Reporting for PHP - screenshot of backtrace PHP Error | Improve Error Reporting for PHP - screenshot of backtrace PHP Error | Improve Error Reporting for PHP - screenshot of backtrace

Les fonctionnalités incluent:

  • trivial à utiliser, c'est juste un fichier
  • erreurs affichées dans le navigateur pour les requêtes normales et ajaxy
  • Les requêtes AJAX sont mises en pause, vous permettant de les réexécuter automatiquement
  • rend les erreurs aussi strictes que possible (encourage la qualité du code et tend à améliorer les performances)
  • extraits de code sur toute la trace de la pile
  • fournit plus d'informations (telles que les signatures de fonctions complètes)
  • corrige certains messages d'erreur qui sont tout simplement faux
  • coloration syntaxique
  • ça a l'air joli!
  • personnalisation
  • l'allumer et l'éteindre manuellement
  • exécuter des sections spécifiques sans rapport d'erreurs
  • ignorer les fichiers vous permettant d'éviter de mettre en évidence le code dans votre trace de pile
  • dossiers de candidature ;ceux-ci sont prioritaires lorsqu'une erreur survient !

Page d'accueil : http://phperror.net/

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

Mon fork (avec des correctifs supplémentaires) : https://github.com/kenorb-contrib/PHP-Error

DTrace

Si votre système prend en charge Traçage dynamique DTrace (installé par défaut sur OS X) et votre PHP est compilé avec les sondes DTrace activées (--enable-dtrace) qui devrait être par défaut, cette commande peut vous aider à déboguer le script PHP en un rien de temps :

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); }'

Donc, étant donné que l'alias suivant a été ajouté à votre RC fichiers (par ex. ~/.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); }"'

vous pouvez retracer votre script avec un alias facile à retenir : trace-php.

Voici un script dtrace plus avancé, enregistrez-le simplement dans dtruss-php.d, rendez-le exécutable (chmod +x dtruss-php.d) et courir:

#!/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));
}

Page d'accueil : lampe à poutres sur GitHub

Voici une utilisation simple :

  1. Courir: sudo dtruss-php.d.
  2. Sur un autre terminal, exécutez : php -r "phpinfo();".

Pour tester cela, vous pouvez accéder à n'importe quel docroot avec index.php et exécutez le serveur PHP intégré en :

php -S localhost:8080

Après cela, vous pouvez accéder au site à http://localhost:8080/ (ou choisissez le port qui vous convient).À partir de là, accédez à certaines pages pour voir la sortie de trace.

Note:Dtrace est disponible par défaut sur OS X, sous Linux vous en aurez probablement besoin dtrace4linux ou vérifiez s'il y en a un autre alternatives.

Voir: Utiliser PHP et DTrace sur php.net


SystèmeTap

Vous pouvez également vérifier le traçage SystemTap en installant le package de développement SystemTap SDT (par ex. yum install systemtap-sdt-devel).

Voici un exemple de script (all_probes.stp) pour tracer tous les principaux points de sonde statique PHP pendant toute la durée d'un script PHP en cours d'exécution avec 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));
}

Usage:

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

Voir: Utilisation de SystemTap avec les sondes statiques PHP DTrace sur php.net

+1 pour print_r().Utilisez-le pour vider le contenu d'un objet ou d'une variable.Pour le rendre plus lisible, faites-le avec une balise pre afin de ne pas avoir besoin d'afficher la source.

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

Aussi var_dump($thing) - c'est très utile pour voir le type de sous-choses

En fonction du problème, j'aime une combinaison de error_reporting(E_ALL) mélangée à des tests d'écho (pour trouver la ligne/le fichier incriminé dans lequel l'erreur s'est produite initialement ;vous SAVEZ que ce n'est pas toujours la ligne/le fichier que php vous dit, n'est-ce pas ?), la correspondance des accolades IDE (pour résoudre "l'erreur d'analyse :erreur de syntaxe, problèmes inattendus de $end") et print_r();sortie;dumps (les vrais programmeurs voient la source ;p).

Vous ne pouvez pas non plus battre phpdebug (vérifier sourceforge) avec "Memory_get_usage ();" et "Memory_get_peak_usage ();" pour trouver les zones problématiques.

Les débogueurs intégrés où vous pouvez observer les valeurs des variables changent au fur et à mesure que vous parcourez le code sont vraiment sympas.Ils nécessitent cependant une configuration logicielle sur le serveur et un certain nombre de configurations sur le client.Les deux nécessitent un entretien périodique pour rester en bon état de fonctionnement.

Un print_r est facile à écrire et est garanti de fonctionner dans n'importe quelle configuration.

Habituellement, je crée une fonction de journal personnalisée capable d'enregistrer dans un fichier, de stocker les informations de débogage et éventuellement de réimprimer sur un pied de page commun.

Vous pouvez également remplacer la classe Exception commune, afin que ce type de débogage soit semi-automatisé.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top