[ 
https://issues.apache.org/jira/browse/NETBEANS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lucio Crusca updated NETBEANS-1959:
-----------------------------------
    Description: 
Product Version = NetBeans 10
 Operating System = Debian GNU/Linux testing/sid up to date
 openjdk version "11.0.1" 2018-10-16
 OpenJDK Runtime Environment 18.9 (build 11.0.1+13)

Reproducibility: Happens every time

I'm not able to debug any PHP project. NB shows "Waiting For Connection 
(xdebug)", and it does not automatically open my PHP website in the browser 
tab, but the internal PHP Debugger state has nothing to do with the wait for 
xdebug connection.

Here is my xdebug configuration, which works correctly at least with Visual 
Studio Code for Linux :

{{zend_extension = /usr/lib/php/20180731/xdebug.so}}
 {{xdebug.remote_autostart = 1}}
 {{xdebug.remote_enable = 1}}
 {{xdebug.remote_handler = dbgp}}
 {{xdebug.remote_host = 127.0.0.1}}
 {{xdebug.remote_mode = req}}
 {{xdebug.remote_port = 9999}}
 {{xdebug.profiler_enable_trigger_value="dbgp"}}
 {{xdebug.trace_enable_trigger_value="dbgp"}}
 {{xdebug.profiler_enable=0}}
 {{xdebug.profiler_enable_trigger=1}}
 {{xdebug.trace_enable_trigger=1}}
 {{xdebug.profiler_output_dir="/var/log/xdebug"}}
 {{xdebug.gc_stats_output_dir="/var/log/xdebug"}}
 {{xdebug.trace_output_dir="/var/log/xdebug"}}
 {{xdebug.remote_log="/var/log/xdebug/remote.log"}}
 {{xdebug.coverage_enable=0}}
 {{xdebug.extended_info=1}}
 {{xdebug.profiler_append=1}}
 {{xdebug.trace_options=1}}
 {{xdebug.collect_params=1}}

I think either NB has a bug at DGBP protocol level, or the "Waiting For 
Connection (xdebug)" message does not reflect the real state of the PHP 
Debugger, at least in my case. More likely the latter.

Here are the contents of /var/log/xdebug/remote.log:

{{[23361] Log opened at 2019-01-20 10:55:27}}
 {{[23361] I: Connecting to configured address/port: 127.0.0.1:9999.}}
 {{[23361] I: Connected to client. :)}}
 {{[23361] -> <init xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; 
fileuri="file:///home/lucio/virtualbit/progetti/workspace/netbeans/bvacance/index.php"
 language="PHP" xdebug:language_version="7.3.0RC3" protocol_version="1.0" 
appid="23361" idekey="lucio"><engine 
version="2.7.0beta1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick 
Rethans]]></author><url><!//xdebug.org]]></url><copyright><![CDATA[Copyright 
(c) 2002-2018 by Derick Rethans]]></copyright></init>}}
 {{[23361]}}
 {{[23361] <- feature_set -i 0 -n show_hidden -v 1}}
 {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="0" feature="show_hidden" success="1"></response>}}
 {{[23361]}}
 {{[23361] <- feature_set -i 1 -n max_depth -v 2}}
 {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="1" feature="max_depth" success="1"></response>}}
 {{[23361]}}
 {{[23361] <- feature_set -i 2 -n max_children -v 30}}
 {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="2" feature="max_children" success="1"></response>}}
 {{[23361]}}
 {{[23361] <- feature_set -i 3 -n max_data -v 65536}}
 {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="3" feature="max_data" success="1"></response>}}
 {{[23361]}}

However, when I try with Visual Studio Code for Linux, which works, the log 
file contents are completely different (which was expected), but a noticeable 
difference is the presence of "breakpoint_set" and "run" commands in the VSC 
case, that are missing in the NB case. 

I suspect NB fails to start the browser tab for some reason and, as a 
consequence, fails to send the appropriate commands to xdebug.

What I know for sure is that the "Waiting For Connection (xdebug)" message is 
misleading at best in my case, because logs show the connection has correctly 
happened, and the problem is elsewhere.

I don't know if we need more precise messages about what's going on in NB to 
sort this out, so I don't know if the bug here is the approximate message, or 
the failure to open the browser tab, or a real problem in the DBGP protocol 
implementation.

Please note that, when I say NB does not open my site in the browser tab, I 
mean NB manages to open a new browser tab, but it fails to redirect it to my 
website, and I get only a new browser tab, pointing to a tmp file and showing a 
blank page.

 

 

  was:
Product Version = NetBeans 10
Operating System = Debian GNU/Linux testing/sid up to date
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)

Reproducibility: Happens every time

I'm not able to debug any PHP project. NB shows "Waiting For Connection 
(xdebug)", and it does not automatically open my PHP website in the browser 
tab, but the internal PHP Debugger state has nothing to do with the wait for 
xdebug connection.

Here is my xdebug configuration, which works correctly at least with Visual 
Studio Code for Linux :

{{zend_extension = /usr/lib/php/20180731/xdebug.so}}
{{xdebug.remote_autostart = 1}}
{{xdebug.remote_enable = 1}}
{{xdebug.remote_handler = dbgp}}
{{xdebug.remote_host = 127.0.0.1}}
{{xdebug.remote_mode = req}}
{{xdebug.remote_port = 9999}}
{{xdebug.profiler_enable_trigger_value="dbgp"}}
{{xdebug.trace_enable_trigger_value="dbgp"}}
{{xdebug.profiler_enable=0}}
{{xdebug.profiler_enable_trigger=1}}
{{xdebug.trace_enable_trigger=1}}
{{xdebug.profiler_output_dir="/var/log/xdebug"}}
{{xdebug.gc_stats_output_dir="/var/log/xdebug"}}
{{xdebug.trace_output_dir="/var/log/xdebug"}}
{{xdebug.remote_log="/var/log/xdebug/remote.log"}}
{{xdebug.coverage_enable=0}}
{{xdebug.extended_info=1}}
{{xdebug.profiler_append=1}}
{{xdebug.trace_options=1}}
{{xdebug.collect_params=1}}

I think either NB has a bug at DGBP protocol level, or the "Waiting For 
Connection (xdebug)" message does not reflect the real state of the PHP 
Debugger, at least in my case. More likely the latter.

Here are the contents of /var/log/xdebug/remote.log:

{{[23361] Log opened at 2019-01-20 10:55:27}}
{{[23361] I: Connecting to configured address/port: 127.0.0.1:9999.}}
{{[23361] I: Connected to client. :-)}}
{{[23361] -> <init xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; 
fileuri="file:///home/lucio/virtualbit/progetti/workspace/netbeans/bvacance/index.php"
 language="PHP" xdebug:language_version="7.3.0RC3" protocol_version="1.0" 
appid="23361" idekey="lucio"><engine 
version="2.7.0beta1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick 
Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright
 (c) 2002-2018 by Derick Rethans]]></copyright></init>}}
{{[23361]}}
{{[23361] <- feature_set -i 0 -n show_hidden -v 1}}
{{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="0" feature="show_hidden" success="1"></response>}}
{{[23361]}}
{{[23361] <- feature_set -i 1 -n max_depth -v 2}}
{{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="1" feature="max_depth" success="1"></response>}}
{{[23361]}}
{{[23361] <- feature_set -i 2 -n max_children -v 30}}
{{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="2" feature="max_children" success="1"></response>}}
{{[23361]}}
{{[23361] <- feature_set -i 3 -n max_data -v 65536}}
{{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
transaction_id="3" feature="max_data" success="1"></response>}}
{{[23361]}}

However, when I try with Visual Studio Code for Linux, which works, the log 
file contents are completely different (which was expected), but a noticeable 
difference is the presence of "breakpoint_set" and "run" commands in the VSC 
case, that are missing in the NB case. 

I suspect NB fails to start the browser tab for some reason and, as a 
consequence, fails to send the appropriate commands to xdebug.

What I know for sure is that the "Waiting For Connection (xdebug)" message is 
misleading at best in my case, because logs show the connection has correctly 
happened, and the problem is elsewhere.

I don't know if we need more precise messages about what's going on in NB to 
sort this out, so I don't know if the bug here is the approximate message, or 
the failure to open the browser tab, or a real problem in the DBGP protocol 
implementation.

Please note that, when I say NB does not open my site in the browser tab, I 
mean NB magages to open a new browser tab, but it fails to redirect it to my 
website, and I get only a new browser tab, pointing to a tmp file and showing a 
blank page.

 

 


> Unable to start debugging PHP (xdebug)
> --------------------------------------
>
>                 Key: NETBEANS-1959
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-1959
>             Project: NetBeans
>          Issue Type: Bug
>          Components: php - Debugger
>    Affects Versions: 10.0, 11.0
>         Environment: OS: Debian GNU/Linux buster/sid amd64
> NB10 - NB11
> OpenJDK 11
> PHP 7.x
>            Reporter: Lucio Crusca
>            Priority: Major
>              Labels: php-debug, php7
>
> Product Version = NetBeans 10
>  Operating System = Debian GNU/Linux testing/sid up to date
>  openjdk version "11.0.1" 2018-10-16
>  OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> Reproducibility: Happens every time
> I'm not able to debug any PHP project. NB shows "Waiting For Connection 
> (xdebug)", and it does not automatically open my PHP website in the browser 
> tab, but the internal PHP Debugger state has nothing to do with the wait for 
> xdebug connection.
> Here is my xdebug configuration, which works correctly at least with Visual 
> Studio Code for Linux :
> {{zend_extension = /usr/lib/php/20180731/xdebug.so}}
>  {{xdebug.remote_autostart = 1}}
>  {{xdebug.remote_enable = 1}}
>  {{xdebug.remote_handler = dbgp}}
>  {{xdebug.remote_host = 127.0.0.1}}
>  {{xdebug.remote_mode = req}}
>  {{xdebug.remote_port = 9999}}
>  {{xdebug.profiler_enable_trigger_value="dbgp"}}
>  {{xdebug.trace_enable_trigger_value="dbgp"}}
>  {{xdebug.profiler_enable=0}}
>  {{xdebug.profiler_enable_trigger=1}}
>  {{xdebug.trace_enable_trigger=1}}
>  {{xdebug.profiler_output_dir="/var/log/xdebug"}}
>  {{xdebug.gc_stats_output_dir="/var/log/xdebug"}}
>  {{xdebug.trace_output_dir="/var/log/xdebug"}}
>  {{xdebug.remote_log="/var/log/xdebug/remote.log"}}
>  {{xdebug.coverage_enable=0}}
>  {{xdebug.extended_info=1}}
>  {{xdebug.profiler_append=1}}
>  {{xdebug.trace_options=1}}
>  {{xdebug.collect_params=1}}
> I think either NB has a bug at DGBP protocol level, or the "Waiting For 
> Connection (xdebug)" message does not reflect the real state of the PHP 
> Debugger, at least in my case. More likely the latter.
> Here are the contents of /var/log/xdebug/remote.log:
> {{[23361] Log opened at 2019-01-20 10:55:27}}
>  {{[23361] I: Connecting to configured address/port: 127.0.0.1:9999.}}
>  {{[23361] I: Connected to client. :)}}
>  {{[23361] -> <init xmlns="urn:debugger_protocol_v1" 
> xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; 
> fileuri="file:///home/lucio/virtualbit/progetti/workspace/netbeans/bvacance/index.php"
>  language="PHP" xdebug:language_version="7.3.0RC3" protocol_version="1.0" 
> appid="23361" idekey="lucio"><engine 
> version="2.7.0beta1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick 
> Rethans]]></author><url><!//xdebug.org]]></url><copyright><![CDATA[Copyright 
> (c) 2002-2018 by Derick Rethans]]></copyright></init>}}
>  {{[23361]}}
>  {{[23361] <- feature_set -i 0 -n show_hidden -v 1}}
>  {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
> xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
> transaction_id="0" feature="show_hidden" success="1"></response>}}
>  {{[23361]}}
>  {{[23361] <- feature_set -i 1 -n max_depth -v 2}}
>  {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
> xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
> transaction_id="1" feature="max_depth" success="1"></response>}}
>  {{[23361]}}
>  {{[23361] <- feature_set -i 2 -n max_children -v 30}}
>  {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
> xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
> transaction_id="2" feature="max_children" success="1"></response>}}
>  {{[23361]}}
>  {{[23361] <- feature_set -i 3 -n max_data -v 65536}}
>  {{[23361] -> <response xmlns="urn:debugger_protocol_v1" 
> xmlns:xdebug="http://xdebug.org/dbgp/xdebug"; command="feature_set" 
> transaction_id="3" feature="max_data" success="1"></response>}}
>  {{[23361]}}
> However, when I try with Visual Studio Code for Linux, which works, the log 
> file contents are completely different (which was expected), but a noticeable 
> difference is the presence of "breakpoint_set" and "run" commands in the VSC 
> case, that are missing in the NB case. 
> I suspect NB fails to start the browser tab for some reason and, as a 
> consequence, fails to send the appropriate commands to xdebug.
> What I know for sure is that the "Waiting For Connection (xdebug)" message is 
> misleading at best in my case, because logs show the connection has correctly 
> happened, and the problem is elsewhere.
> I don't know if we need more precise messages about what's going on in NB to 
> sort this out, so I don't know if the bug here is the approximate message, or 
> the failure to open the browser tab, or a real problem in the DBGP protocol 
> implementation.
> Please note that, when I say NB does not open my site in the browser tab, I 
> mean NB manages to open a new browser tab, but it fails to redirect it to my 
> website, and I get only a new browser tab, pointing to a tmp file and showing 
> a blank page.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to