php - simbolo - punto de interrupcion visual studio 2017

La depuración remota no se detendrá en los puntos de interrupción (19)

Tuve el mismo problema, y finalmente descubrí que a mi php.ini le faltaban estas dos configuraciones importantes:

xdebug.remote_autostart = "On" xdebug.remote_enable = "On"

Entonces funcionó perfectamente.

Tengo un problema con xdebug que no se detiene en los puntos de interrupción cuando se utiliza la depuración remota (todo está bien cuando se ejecutan scripts a través de la línea de comandos). Se romperá en la primera línea del programa, luego saldrá, sin atrapar ningún punto de interrupción.

Solía funcionar bien, hasta que cambié al uso de MacPorts para Apache y PHP. Intenté volver a compilarlo varias veces (con varias versiones), pero sin dados.

Estoy usando PHP 5.3.1 y Xdebug 2.1.0-beta3

También probé al menos 3 programas de depuración diferentes (MacGDBp, Netbeans y JetBrains Web IDE).

Mi configuración php.ini se ve así:

[xdebug] xdebug.remote_enable=1 xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_port=9000 xdebug.remote_host=localhost xdebug.idekey=webide

Y cuando registro la salida del depurador, establecer un punto de interrupción se ve así /;

<- breakpoint_set -i 895 -t line -f file:///Users/WM_imac/Sites/wm/debug_test.php -n 13 -s enabled -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="895" state="enabled" id="890660002"></response>

Cuando se ejecuta, el depurador obtendrá el contexto de la primera línea de la aplicación, luego enviará los mensajes de separación y detención.

Sin embargo, esta línea sale cuando se inicia el depurador.

<- feature_get -i 885 -n breakpoint_types -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_get" transaction_id="885" feature_name="breakpoint_types" supported="1"><![CDATA[line conditional call return exception]]></response>

¿Significa algo ''excepción de devolución de llamada condicional''?

desde http://xdebug.org/docs/install , "Debería ignorar cualquier indicación para agregar" extension = xdebug.so "a php.ini; esto causará problemas".

entonces, esto lo solucionó para mí:

en el archivo config, donde carga la extensión xdebug (para mí, para la versión CLI de php, que era /etc/php5/cli/conf.d/xdebug.ini) - no especifique

extension = xdebug.so

en cambio, usa

zend_extension = / ruta / a / xdebug / module / xdebug.so

(Para mí, esto era algo así como /usr/lib/php5/(...)/xdebug.so)

¿Podría proporcionar un registro completo de la sesión mientras intenta depurar con Web IDE?

Por cierto, al usar Web IDE, normalmente no es necesario establecer xdebug.idekey = webide, ya que la clave ide se asigna automáticamente a través del parámetro url.

Me conecto con eso de vez en cuando y nunca he podido averiguar la verdadera causa del problema.

Suelo resolver por,

Colocando más puntos de interrupción en el código del cliente construyendo las instancias y cargando las clases (ya que parece que XDebug ignorará algunos puntos de interrupción debido a problemas de carga de clases). Puede aprender y darse cuenta de dónde están estas ubicaciones haciendo algunos pasos.
Verifique las rutas de origen de las dependencias. XDebug recoge estos archivos por sus rutas completas, puede ver cómo su IDE los aborda en su panel de punto de interrupción.

XDebug funciona bien en mi cuadro Ubuntu Lucid usando NetBeans, y tengo la línea zend_extension en mi php.ini (/etc/php5/apache2/php.ini).

Estoy usando netbeans 6.9 y PHP 5.2 con xdebug 2.0.4-2

Estoy pegando las líneas relevantes aquí, espero que ayude:

zend_extension=/usr/lib/php5/20060613/xdebug.so [debug] ; Remote settings xdebug.remote_autostart=on xdebug.remote_enable=on xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_host=localhost xdebug.remote_port=9000 xdebug.idekey="netbeans-xdebug" ; General xdebug.auto_trace=off xdebug.collect_includes=on xdebug.collect_params=off xdebug.collect_return=off xdebug.default_enable=on xdebug.extended_info=1 xdebug.manual_url=http://www.php.net xdebug.show_local_vars=1 xdebug.show_mem_delta=0 xdebug.max_nesting_level=100 ;xdebug.idekey= ; Trace options xdebug.trace_format=0 xdebug.trace_output_dir=/tmp xdebug.trace_options=0 xdebug.trace_output_name=crc32 ; Profiling xdebug.profiler_append=0 xdebug.profiler_enable=0 xdebug.profiler_enable_trigger=0 xdebug.profiler_output_dir=/tmp xdebug.profiler_output_name=crc32

He tenido el mismo problema, la solución para mí era tener el código local en la misma ruta que el código remoto.

Ejemplo

En el servidor web, el código estaba ubicado en la ruta: /var/www/dev01/app_name

Localmente, el código estaba ubicado en mi directorio principal: /home/me/projects/app_name

Esta configuración causó que mi IDE (Eclipse y Komodo) pasara directamente por los puntos de corte.

Cambiar la ruta local desde /home/me/projects/app_name a /var/www/dev01/app_name solucionó el problema. Usar sshfs para montar localmente el sistema de archivos remoto lo hace aún más fácil.

Acabo de experimentar algo similar al comentario de safl anterior usando Komodo pero no estoy seguro si está relacionado:

Tengo xdebug configurado usando zend_extension con Komodo y funciona perfectamente, puede establecer puntos de interrupción y xdebug_break (), pero solo algunos archivos. Otros no funcionaron

La solución estaba en la forma en que se produjo el mapeo de las rutas locales y remotas. Resulta que Komodo está haciendo una comparación sensible a mayúsculas y minúsculas en el nombre de la ruta, por lo que mi asignación no coincide. Los archivos que el depurador abrió al pasar estaban en el camino correcto, pero los archivos que abrí a través del identificador tenían una letra en mayúsculas que aparentemente causó que Komodo pasara por alto.

Tuve este problema y me llevó años encontrar la respuesta.

En su configuración de depuración, en el área del servidor, haga clic en Configurar, vaya a Asignación de ruta, haga clic en la ruta que está allí y haga clic en editar, cambie a Ruta en el sistema de archivos y navegue hasta el archivo correcto.

Hecho.

Me encontré con esta misma cosa exacta y estaba golpeando mi cabeza contra ella por un tiempo. En algún momento también había agregado ZendDebugger.so a mi PHP.ini y eso era lo que estaba rompiendo Xdebug. Comentando la línea ZendDebugger.so en mi php.ini lo arreglé.

Si no está utilizando ZendDebugger, puede comenzar a deshabilitar otras extensiones de Zend y ver si se trata de otra extensión que causa el conflicto.

En mi caso, el problema estaba sucediendo en un solo proyecto (solo pude romper utilizando xdebug_break), mientras que en los otros proyectos estaba funcionando bien.

Fue arreglado editando el archivo: nbproject / private / private.properties : Y set:

copy.src.files=false

Cuando creé el proyecto, seleccioné la opción "copiar fuentes" por error. Luego moví manualmente el proyecto y edité su ruta de origen (en el archivo "nbproject / project.properties"), que el depurador todavía estaba buscando la ruta anterior (establecida en copy.src.target).

Entonces, técnicamente, otra forma de solucionar este problema DEBUG es volver a crear el directorio nbproject (quitándolo y creando el proyecto nuevamente). Supongo que el depurador debería funcionar bien con la opción "copiar" habilitada (ya que nunca la utilizo).

Espero que esto pueda ayudar.

Probé todas estas soluciones sin éxito. Estaba confundido porque XDebug trabajó para uno de mis proyectos, pero no este nuevo. Después de tropezar al comparar las propiedades de configuración, me di cuenta de que

Propiedades del proyecto> Fuentes> Raíz web:

el valor se estableció en un default value en el nuevo proyecto, pero se estableció en webroot en el proyecto existente. Por lo tanto, busqué en el webroot del proyecto y establecí ese valor. Lo probé y, bada-bing, funcionó.

Yo uso Eclipse y también busqué por un tiempo. Todas las cosas en php.ini han sido correctas.

Al final, descubrí que en Eclipse el depurador estaba configurado para ZEND-Debugger . Después de que lo cambié a XDEBUG , funcionó bien.

Saludos Joerg

Tuve un problema similar y encontré una publicación para solucionar el problema. Mi formulario html (testform.html) llamaba a un script php (runQuery.php) y Netbeans no podía romper en los puntos de interrupción establecidos en mi runQuery.php

Después de verificar todas las configuraciones en php.ini y Netbeans buscando en foros como este, descubrí que netbeans solo romperá los puntos de quiebre si el archivo de índice para el proyecto es un archivo PHP. Esto es muy importante, de lo contrario pasarás horas tratando de descubrir por qué los puntos de quiebre no funcionan.

En Netbeans vaya a Archivo / Propiedades del proyecto / Configuración de ejecución y verifique que el archivo de índice sea un archivo PHP. En mi caso cambié mi archivo de índice de testform.html a testform.php y funcionó, pude romper los puntos de quiebre.

Cuando se trata de rutas, el sistema de archivos OSX no distingue entre mayúsculas y minúsculas, pero xdebug parece serlo.

En mi caso todo parecía funcionar a pesar de que estaba ejecutando el script usando / p roj / test.php en lugar de / P roj / test.php.

Cuando xdebug (o al menos la versión que tengo actualmente) está buscando puntos de corte, la verificación distingue mayúsculas de minúsculas. Si el punto de ruptura se establece para /Proj/test.php, pero el script se ejecuta a través de /proj/test.php, entonces no hay coincidencia.

También tuve un problema similar con la ruta de inclusión de PHP. La ruta incluía / proj -directory, que estaba mal. Ejecutar el código funcionó, pero dado que los puntos de interrupción se establecieron usando / Proj, no fueron afectados.

Para verificar si este es el problema:

Habilitar el registro, -dxdebug.remote_log = / tmp / remote.log
Compruebe la ruta exacta en el registro cuando se establecen puntos de interrupción
Compare el camino al PHP que está usando el intepreter, por ejemplo: echo dirname (__ FILE__);

También puede haber un problema con símbolos inusuales en la ruta. Por ejemplo, mi código estaba ubicado por ruta:

C:/[dev]/OpenServer/domains/...

Y no pude detectar nada, pero después de cambiar el problema de ruta desapareció:

C:/dev/OpenServer/domains/...

Así que incluso los corchetes importan.

Estaba intentando depurar con PhpStorm, pero no se detuvo en algunos puntos críticos y empecé a ignorar aún más ya que estaba probando cada solución que podía encontrar con Google.

El problema fue que había múltiples procesos separados de PHP ejecutándose en segundo plano que realmente manejaban mis solicitudes. PhpStorm no se detuvo en puntos de interrupción porque el proceso que estaba depurando no recibía solicitudes. Matar estos procesos me lo resolvió.

No puedo comentar una publicación, por lo tanto, esta publicación.

La solución a mi problema era muy parecida a la de pitchandtone. Eclipce había hecho elementos de mapeo incorrectos y de doble trayectoria. Sin embargo, podría usar las rutas relativas (es decir, / proyecto / carpeta).

Odio estas configuraciones. Mi vida cambió cuando conocí el Lib Dephpugger.

Es un depurador para ejecutar en la terminal (como ipdb para Python y byebug para Ruby). https://github.com/tacnoman/dephpugger Es muy fácil de usar.

¿Estás totalmente seguro de que no estás cargando el Xdebug a través de la extension=xdebug.so ? Xdebug se cargará si esta línea aparece en tu php.ini (es decir, aparece en el resultado de phpinfo() , etc.) pero los puntos de interrupción no funcionan si se cargan de esta manera. (Incluso se conectará a clientes de depuración y aceptará puntos de interrupción; nunca se activarán).

Te sugiero que zend_extension línea zend_extension y veas si todavía está cargada; podrías pensar que estás cargando Xdebug a través de /etc/php5/conf.d/xdebug.ini, por ejemplo, pero algo lo ha agregado a /etc/php5/apache2/php.ini a tus espaldas.

Vea esta pregunta y respuesta para más información.