Home » Language IDEs » PHP Development Tools (PDT) » how to start and XDebug session in PDT Debugger without launching a browser?
| how to start and XDebug session in PDT Debugger without launching a browser? [message #51885] |
Fri, 14 September 2007 19:23  |
 Edward Pring
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
I'm still trying to use the PDT Debugger to debug PHP scripts that
implement REST and SOAP web services for clients that are application
programs, not browsers.
For my runtime, I have switched to the "xampp 1.6.3a" package (Apache
2.2.4 and PHP 5.2.3,0), and enabled XDebug 2.0.0 (and disabled the Zend
Optimizer). For my IDE, I am still using "Eclipse PDT
all-in-one-incubation S20070910 RC1", but I have re-configured the PDT
Debugger to use XDebug instead of Zend.
I can start a PDT Debugger session with the Eclipse "Debug As -> PHP Web
Page" action. I can then cause the PHP engine to connect to the PDT
Debugger when it executes PHP scripts by adding two debugger-related
arguments to URLs in Java or C applications, like this:
http://localhost/whatever/index.php
?XDEBUG_SESSION_START=ECLIPSE_DBGP
&KEY=11897922781713
The "KEY=xxxxx" argument does not seem to be necessary; at least, in my
tests, the PHP engine connects to the PDT Debugger when it is omitted
from URLs in Java and C applications.
Thanks to a link provided by Schreck, I found Dave Kelsey's excellent
"XDebug Guide" document (see http://www.eclipse.org/pdt/docs.php), but I
still have a few questions:
(*) How can I launch the PDT Debugger without also launching a browser?
That is, how can I just start an instance of "PHP Application, Remote
Launch" (in the Eclipse "Debug" view)? The "Debug As -> PHP Web Page"
action does this, but also starts an instance of a browser.
(*) Is the "KEY=xxxx" argument really needed, and if so, how is it used?
(*) How does XDebug use cookies?
-- Edward Pring <pring@us.ibm.com>
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #51912 is a reply to message #51885] |
Fri, 14 September 2007 22:10  |
D Kelsey
Messages: 232
Registered: July 2009 |
Senior Member |
|
|
Hi Edward, see embedded comments.
Dave Kelsey
Edward Pring wrote:
> I'm still trying to use the PDT Debugger to debug PHP scripts that
> implement REST and SOAP web services for clients that are application
> programs, not browsers.
>
> For my runtime, I have switched to the "xampp 1.6.3a" package (Apache
> 2.2.4 and PHP 5.2.3,0), and enabled XDebug 2.0.0 (and disabled the Zend
> Optimizer). For my IDE, I am still using "Eclipse PDT
> all-in-one-incubation S20070910 RC1", but I have re-configured the PDT
> Debugger to use XDebug instead of Zend.
>
> I can start a PDT Debugger session with the Eclipse "Debug As -> PHP Web
> Page" action. I can then cause the PHP engine to connect to the PDT
> Debugger when it executes PHP scripts by adding two debugger-related
> arguments to URLs in Java or C applications, like this:
>
> http://localhost/whatever/index.php
> ?XDEBUG_SESSION_START=ECLIPSE_DBGP
> &KEY=11897922781713
>
> The "KEY=xxxxx" argument does not seem to be necessary; at least, in my
> tests, the PHP engine connects to the PDT Debugger when it is omitted
> from URLs in Java and C applications.
>
> Thanks to a link provided by Schreck, I found Dave Kelsey's excellent
> "XDebug Guide" document (see http://www.eclipse.org/pdt/docs.php), but I
> still have a few questions:
>
> (*) How can I launch the PDT Debugger without also launching a browser?
> That is, how can I just start an instance of "PHP Application, Remote
> Launch" (in the Eclipse "Debug" view)? The "Debug As -> PHP Web Page"
> action does this, but also starts an instance of a browser.
>
You don't. That is the purpose of the web launch. It invokes the URL via a web browser and
sets up the environment to start a debugging session. The only way to get around this
is to write your own launcher for eclipse.
> (*) Is the "KEY=xxxx" argument really needed, and if so, how is it used?
The key is used to get around an issue with Internet Explorer where is caches
the page based on the URL. Eclipse would use IE as the internal web browser
and without using something that changed the URL you saw the same results being
displayed even though you had changed the script.
>
> (*) How does XDebug use cookies?
>
Xdebug uses a cookie to determine if it should try to establish a debug connection or not
and what value it should pass as the ide key. If the cookie is set then it attempts to
connect to the debug client and passes the value as the ide key. For more info
on xdebug go to http://www.xdebug.org
> -- Edward Pring <pring@us.ibm.com>
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53021 is a reply to message #51912] |
Wed, 19 September 2007 13:55 |
Edward Pring
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Dave Kelsey wrote:
> Hi Edward, see embedded comments.
>
> Dave Kelsey
>
> Edward Pring wrote:
>> I'm still trying to use the PDT Debugger to debug PHP scripts that
>> implement REST and SOAP web services for clients that are application
>> programs, not browsers.
>>
>> For my runtime, I have switched to the "xampp 1.6.3a" package (Apache
>> 2.2.4 and PHP 5.2.3,0), and enabled XDebug 2.0.0 (and disabled the
>> Zend Optimizer). For my IDE, I am still using "Eclipse PDT
>> all-in-one-incubation S20070910 RC1", but I have re-configured the PDT
>> Debugger to use XDebug instead of Zend.
>>
>> I can start a PDT Debugger session with the Eclipse "Debug As -> PHP
>> Web Page" action. I can then cause the PHP engine to connect to the
>> PDT Debugger when it executes PHP scripts by adding two
>> debugger-related arguments to URLs in Java or C applications, like this:
>>
>> http://localhost/whatever/index.php
>> ?XDEBUG_SESSION_START=ECLIPSE_DBGP
>> &KEY=11897922781713
>>
>> The "KEY=xxxxx" argument does not seem to be necessary; at least, in
>> my tests, the PHP engine connects to the PDT Debugger when it is
>> omitted from URLs in Java and C applications.
>>
>> Thanks to a link provided by Schreck, I found Dave Kelsey's excellent
>> "XDebug Guide" document (see http://www.eclipse.org/pdt/docs.php), but
>> I still have a few questions:
>>
>> (*) How can I launch the PDT Debugger without also launching a
>> browser? That is, how can I just start an instance of "PHP
>> Application, Remote Launch" (in the Eclipse "Debug" view)? The "Debug
>> As -> PHP Web Page" action does this, but also starts an instance of a
>> browser.
>>
> You don't. That is the purpose of the web launch. It invokes the URL via
> a web browser and
> sets up the environment to start a debugging session. The only way to
> get around this
> is to write your own launcher for eclipse.
>
>> (*) Is the "KEY=xxxx" argument really needed, and if so, how is it used?
> The key is used to get around an issue with Internet Explorer where is
> caches
> the page based on the URL. Eclipse would use IE as the internal web browser
> and without using something that changed the URL you saw the same
> results being
> displayed even though you had changed the script.
>
>>
>> (*) How does XDebug use cookies?
>>
> Xdebug uses a cookie to determine if it should try to establish a debug
> connection or not
> and what value it should pass as the ide key. If the cookie is set then
> it attempts to
> connect to the debug client and passes the value as the ide key. For
> more info
> on xdebug go to http://www.xdebug.org
>
>
>
>> -- Edward Pring <pring@us.ibm.com>
I see. For now, I have a work-around with the existing Eclipse
launcher, but the PDT Debugger does not seem to honor breakpoints.
I'm using the "Debug As -> PHP Web Page" action with a trivial PHP
script. The launcher is configured with "Break at first line" checked
and "Debug all pages" selected.
I click "Resume" immediately when the PDT Debugger stops on entry to the
trivial PHP script, and the debugger remains active, with Eclipse
listening on ports 9000 and 10000.
Later, when I run a Java client application that invokes another PHP
script on the same web server, the PHP engine connects to Eclipse on
port 9000, and the PDT Debugger stops on entry to the other PHP script.
I can step through the PHP script with the "Step Over" and "Step Into"
buttons, and the "Variables" view shows all of the variables in the PHP
script correctly.
I can set breakpoints in the PHP script, but they don't seem to work.
There are two symptoms:
(*) When I set breakpoints in the PHP script, they appear in the
"Breakpoints" view with the proper file names and line numbers, but the
"green dot" annotation does not appear in the left border of the source
file editor.
(*) When I click "Resume", the PHP script runs to completion. The PDT
Debugger does not stop on any of the breakpoints in the script.
There are no messages related to this in the "workspace/.metadata/.log"
file. Am I missing something in my configuration?
-- Edward Pring <pring@us.ibm.com>
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53045 is a reply to message #53021] |
Wed, 19 September 2007 14:56 |
Edward Pring
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
This is a multi-part message in MIME format.
--------------050502050708090807040204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Edward Pring wrote:
> Dave Kelsey wrote:
>> Hi Edward, see embedded comments.
>>
>> Dave Kelsey
>>
>> Edward Pring wrote:
>>> I'm still trying to use the PDT Debugger to debug PHP scripts that
>>> implement REST and SOAP web services for clients that are application
>>> programs, not browsers.
>>>
>>> For my runtime, I have switched to the "xampp 1.6.3a" package (Apache
>>> 2.2.4 and PHP 5.2.3,0), and enabled XDebug 2.0.0 (and disabled the
>>> Zend Optimizer). For my IDE, I am still using "Eclipse PDT
>>> all-in-one-incubation S20070910 RC1", but I have re-configured the
>>> PDT Debugger to use XDebug instead of Zend.
>>>
>>> I can start a PDT Debugger session with the Eclipse "Debug As -> PHP
>>> Web Page" action. I can then cause the PHP engine to connect to the
>>> PDT Debugger when it executes PHP scripts by adding two
>>> debugger-related arguments to URLs in Java or C applications, like this:
>>>
>>> http://localhost/whatever/index.php
>>> ?XDEBUG_SESSION_START=ECLIPSE_DBGP
>>> &KEY=11897922781713
>>>
>>> The "KEY=xxxxx" argument does not seem to be necessary; at least, in
>>> my tests, the PHP engine connects to the PDT Debugger when it is
>>> omitted from URLs in Java and C applications.
>>>
>>> Thanks to a link provided by Schreck, I found Dave Kelsey's excellent
>>> "XDebug Guide" document (see http://www.eclipse.org/pdt/docs.php),
>>> but I still have a few questions:
>>>
>>> (*) How can I launch the PDT Debugger without also launching a
>>> browser? That is, how can I just start an instance of "PHP
>>> Application, Remote Launch" (in the Eclipse "Debug" view)? The
>>> "Debug As -> PHP Web Page" action does this, but also starts an
>>> instance of a browser.
>>>
>> You don't. That is the purpose of the web launch. It invokes the URL
>> via a web browser and
>> sets up the environment to start a debugging session. The only way to
>> get around this
>> is to write your own launcher for eclipse.
>>
>>> (*) Is the "KEY=xxxx" argument really needed, and if so, how is it used?
>> The key is used to get around an issue with Internet Explorer where is
>> caches
>> the page based on the URL. Eclipse would use IE as the internal web
>> browser
>> and without using something that changed the URL you saw the same
>> results being
>> displayed even though you had changed the script.
>>
>>>
>>> (*) How does XDebug use cookies?
>>>
>> Xdebug uses a cookie to determine if it should try to establish a
>> debug connection or not
>> and what value it should pass as the ide key. If the cookie is set
>> then it attempts to
>> connect to the debug client and passes the value as the ide key. For
>> more info
>> on xdebug go to http://www.xdebug.org
>>
>>
>>
>>> -- Edward Pring <pring@us.ibm.com>
>
> I see. For now, I have a work-around with the existing Eclipse
> launcher, but the PDT Debugger does not seem to honor breakpoints.
>
> I'm using the "Debug As -> PHP Web Page" action with a trivial PHP
> script. The launcher is configured with "Break at first line" checked
> and "Debug all pages" selected.
>
> I click "Resume" immediately when the PDT Debugger stops on entry to the
> trivial PHP script, and the debugger remains active, with Eclipse
> listening on ports 9000 and 10000.
>
> Later, when I run a Java client application that invokes another PHP
> script on the same web server, the PHP engine connects to Eclipse on
> port 9000, and the PDT Debugger stops on entry to the other PHP script.
>
> I can step through the PHP script with the "Step Over" and "Step Into"
> buttons, and the "Variables" view shows all of the variables in the PHP
> script correctly.
>
> I can set breakpoints in the PHP script, but they don't seem to work.
> There are two symptoms:
>
> (*) When I set breakpoints in the PHP script, they appear in the
> "Breakpoints" view with the proper file names and line numbers, but the
> "green dot" annotation does not appear in the left border of the source
> file editor.
>
> (*) When I click "Resume", the PHP script runs to completion. The PDT
> Debugger does not stop on any of the breakpoints in the script.
>
> There are no messages related to this in the "workspace/.metadata/.log"
> file. Am I missing something in my configuration?
>
> -- Edward Pring <pring@us.ibm.com>
I've done a bit more testing with a Java client application that invokes
a PHP script, and I think I've found another problem in the PDT Debugger.
My Java client application invokes the PHP script seven times,
alternating between GET and POST, with slightly different query
arguments each time.
The PDT Debugger always stops on entry to the PHP script the first and
second times it is invoked, but after that it misses some invocations,
seemingly at random. For example, in successive runs of the Java client
application, the PDT Debugger stopped on these invocations:
run 1: PDT Debugger stopped on invocations 1, 2, 4, 7
run 1: PDT Debugger stopped on invocations 1, 2, 5
run 1: PDT Debugger stopped on invocations 1, 2, 6
My Java client is correctly caching the Cookie returned in each response
message and submitting it with the next request message, and the HTTP is
pretty simple. A snippet of the log is attached to this message.
Again, there are no messages related to this in the
"workspace/.metadata/.log" file.
Should I report this (and the missed breakpoints described above) as
bugs? If so, is there additional diagnostic information I can collect?
-- Edward Pring <pring@us.ibm.com>
--------------050502050708090807040204
Content-Type: text/plain;
name="JSONtest.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="JSONtest.log"
DEBUG request: POST /JSONtest/index.php?test=1&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: text/*, application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Content-Length: 54
DEBUG request header[4]: Content-Type: application/json
DEBUG request content: [ { "key1": "string", "key2": 42, "key3": 3.14159 } ]
DEBUG response: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:40 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:40 GMT; path=/
DEBUG response header[4]: Content-Length: 2
DEBUG response header[5]: Content-Type: text/plain
DEBUG response content: OK
DEBUG request: GET /JSONtest/index.php?test=2&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Cookie: $Version=0; XDEBUG_SESSION=ECLIPSE_DBGP; $Path=/
DEBUG response status: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:46 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:46 GMT; path=/
DEBUG response header[4]: Content-Length: 12
DEBUG response header[5]: Content-Type: application/json
DEBUG response content: {"test":"2"}
DEBUG request: POST /JSONtest/index.php?test=3&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: text/*, application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Cookie: $Version=0; XDEBUG_SESSION=ECLIPSE_DBGP; $Path=/
DEBUG request header[4]: Content-Length: 54
DEBUG request header[5]: Content-Type: application/json
DEBUG request content: [ { "key1": "string", "key2": 42, "key3": 3.14159 } ]
DEBUG response: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:50 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:50 GMT; path=/
DEBUG response header[4]: Content-Length: 2
DEBUG response header[5]: Content-Type: text/plain
DEBUG response content: OK
DEBUG request: GET /JSONtest/index.php?test=4&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Cookie: $Version=0; XDEBUG_SESSION=ECLIPSE_DBGP; $Path=/
DEBUG response status: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:50 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:50 GMT; path=/
DEBUG response header[4]: Content-Length: 12
DEBUG response header[5]: Content-Type: application/json
DEBUG response content: {"test":"4"}
--------------050502050708090807040204--
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53072 is a reply to message #53021] |
Wed, 19 September 2007 15:03 |
Edward Pring
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
This is a multi-part message in MIME format.
--------------010305060207030302050508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Edward Pring wrote:
> Dave Kelsey wrote:
>> Hi Edward, see embedded comments.
>>
>> Dave Kelsey
>>
>> Edward Pring wrote:
>>> I'm still trying to use the PDT Debugger to debug PHP scripts that
>>> implement REST and SOAP web services for clients that are application
>>> programs, not browsers.
>>>
>>> For my runtime, I have switched to the "xampp 1.6.3a" package (Apache
>>> 2.2.4 and PHP 5.2.3,0), and enabled XDebug 2.0.0 (and disabled the
>>> Zend Optimizer). For my IDE, I am still using "Eclipse PDT
>>> all-in-one-incubation S20070910 RC1", but I have re-configured the
>>> PDT Debugger to use XDebug instead of Zend.
>>>
>>> I can start a PDT Debugger session with the Eclipse "Debug As -> PHP
>>> Web Page" action. I can then cause the PHP engine to connect to the
>>> PDT Debugger when it executes PHP scripts by adding two
>>> debugger-related arguments to URLs in Java or C applications, like this:
>>>
>>> http://localhost/whatever/index.php
>>> ?XDEBUG_SESSION_START=ECLIPSE_DBGP
>>> &KEY=11897922781713
>>>
>>> The "KEY=xxxxx" argument does not seem to be necessary; at least, in
>>> my tests, the PHP engine connects to the PDT Debugger when it is
>>> omitted from URLs in Java and C applications.
>>>
>>> Thanks to a link provided by Schreck, I found Dave Kelsey's excellent
>>> "XDebug Guide" document (see http://www.eclipse.org/pdt/docs.php),
>>> but I still have a few questions:
>>>
>>> (*) How can I launch the PDT Debugger without also launching a
>>> browser? That is, how can I just start an instance of "PHP
>>> Application, Remote Launch" (in the Eclipse "Debug" view)? The
>>> "Debug As -> PHP Web Page" action does this, but also starts an
>>> instance of a browser.
>>>
>> You don't. That is the purpose of the web launch. It invokes the URL
>> via a web browser and
>> sets up the environment to start a debugging session. The only way to
>> get around this
>> is to write your own launcher for eclipse.
>>
>>> (*) Is the "KEY=xxxx" argument really needed, and if so, how is it used?
>> The key is used to get around an issue with Internet Explorer where is
>> caches
>> the page based on the URL. Eclipse would use IE as the internal web
>> browser
>> and without using something that changed the URL you saw the same
>> results being
>> displayed even though you had changed the script.
>>
>>>
>>> (*) How does XDebug use cookies?
>>>
>> Xdebug uses a cookie to determine if it should try to establish a
>> debug connection or not
>> and what value it should pass as the ide key. If the cookie is set
>> then it attempts to
>> connect to the debug client and passes the value as the ide key. For
>> more info
>> on xdebug go to http://www.xdebug.org
>>
>>
>>
>>> -- Edward Pring <pring@us.ibm.com>
>
> I see. For now, I have a work-around with the existing Eclipse
> launcher, but the PDT Debugger does not seem to honor breakpoints.
>
> I'm using the "Debug As -> PHP Web Page" action with a trivial PHP
> script. The launcher is configured with "Break at first line" checked
> and "Debug all pages" selected.
>
> I click "Resume" immediately when the PDT Debugger stops on entry to the
> trivial PHP script, and the debugger remains active, with Eclipse
> listening on ports 9000 and 10000.
>
> Later, when I run a Java client application that invokes another PHP
> script on the same web server, the PHP engine connects to Eclipse on
> port 9000, and the PDT Debugger stops on entry to the other PHP script.
>
> I can step through the PHP script with the "Step Over" and "Step Into"
> buttons, and the "Variables" view shows all of the variables in the PHP
> script correctly.
>
> I can set breakpoints in the PHP script, but they don't seem to work.
> There are two symptoms:
>
> (*) When I set breakpoints in the PHP script, they appear in the
> "Breakpoints" view with the proper file names and line numbers, but the
> "green dot" annotation does not appear in the left border of the source
> file editor.
>
> (*) When I click "Resume", the PHP script runs to completion. The PDT
> Debugger does not stop on any of the breakpoints in the script.
>
> There are no messages related to this in the "workspace/.metadata/.log"
> file. Am I missing something in my configuration?
>
> -- Edward Pring <pring@us.ibm.com>
I've done a bit more testing with a Java client application that invokes
a PHP script, and I think I've found another problem in the PDT Debugger.
My Java client application invokes the PHP script seven times,
alternating between GET and POST, with slightly different query
arguments each time.
The PDT Debugger always stops on entry to the PHP script the first and
second times it is invoked, but after that it misses some invocations,
seemingly at random. For example, in successive runs of the Java client
application, the PDT Debugger stopped on these invocations:
run 1: PDT Debugger stopped on invocations 1, 2, 4, 7
run 2: PDT Debugger stopped on invocations 1, 2, 5
run 3: PDT Debugger stopped on invocations 1, 2, 6
My Java client is correctly caching the Cookie returned in each response
message and submitting it with the next request message, and the HTTP is
pretty simple. A snippet of the log is attached to this message.
Again, there are no messages related to this in the
"workspace/.metadata/.log" file.
Should I report this (and the missed breakpoints described above) as
bugs? If so, is there additional diagnostic information I can collect?
-- Edward Pring <pring@us.ibm.com>
--------------010305060207030302050508
Content-Type: text/plain;
name="JSONtest.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="JSONtest.log"
DEBUG request: POST /JSONtest/index.php?test=1&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: text/*, application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Content-Length: 54
DEBUG request header[4]: Content-Type: application/json
DEBUG request content: [ { "key1": "string", "key2": 42, "key3": 3.14159 } ]
DEBUG response: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:40 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:40 GMT; path=/
DEBUG response header[4]: Content-Length: 2
DEBUG response header[5]: Content-Type: text/plain
DEBUG response content: OK
DEBUG request: GET /JSONtest/index.php?test=2&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Cookie: $Version=0; XDEBUG_SESSION=ECLIPSE_DBGP; $Path=/
DEBUG response status: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:46 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:46 GMT; path=/
DEBUG response header[4]: Content-Length: 12
DEBUG response header[5]: Content-Type: application/json
DEBUG response content: {"test":"2"}
DEBUG request: POST /JSONtest/index.php?test=3&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: text/*, application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Cookie: $Version=0; XDEBUG_SESSION=ECLIPSE_DBGP; $Path=/
DEBUG request header[4]: Content-Length: 54
DEBUG request header[5]: Content-Type: application/json
DEBUG request content: [ { "key1": "string", "key2": 42, "key3": 3.14159 } ]
DEBUG response: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:50 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:50 GMT; path=/
DEBUG response header[4]: Content-Length: 2
DEBUG response header[5]: Content-Type: text/plain
DEBUG response content: OK
DEBUG request: GET /JSONtest/index.php?test=4&XDEBUG_SESSION_START=ECLIPSE_ DBGP&KEY=javaclient
DEBUG request header[0]: Accept: application/json
DEBUG request header[1]: User-Agent: Jakarta Commons-HttpClient/3.1
DEBUG request header[2]: Host: localhost
DEBUG request header[3]: Cookie: $Version=0; XDEBUG_SESSION=ECLIPSE_DBGP; $Path=/
DEBUG response status: HTTP/1.1 200 OK
DEBUG response header[0]: Date: Wed, 19 Sep 2007 14:32:50 GMT
DEBUG response header[1]: Server: Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.3
DEBUG response header[2]: X-Powered-By: PHP/5.2.3
DEBUG response header[3]: Set-Cookie: XDEBUG_SESSION=ECLIPSE_DBGP; expires=Wed, 19-Sep-2007 15:32:50 GMT; path=/
DEBUG response header[4]: Content-Length: 12
DEBUG response header[5]: Content-Type: application/json
DEBUG response content: {"test":"4"}
--------------010305060207030302050508--
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53103 is a reply to message #53072] |
Wed, 19 September 2007 16:38 |
D Kelsey
Messages: 232
Registered: July 2009 |
Senior Member |
|
|
The Web launch is not designed to work in the manner you are describing
so there is every likelyhood that breakpoints will not work. The
Web launch has automated path mapping which is probably what is interfering
with breakpoints being set correctly, not sure why they don't show up in
the editor though.
The only way for automated path mapping to be disabled is for the
script that is executed by the web server is the one held in your workspace
ie your document root points to your PDT workspace.
There could be many reasons why you are seeing the other problem you
are describing. For example you can only have one web launch active and a web launch
can only handle one session at a time. The previous session must end
and be terminated before the next session tries to start otherwise it
is ignored, one way to find out would be to have a delay between each
invocation to allow the web launch to go through the termination process.
Dave Kelsey
>> I see. For now, I have a work-around with the existing Eclipse
>> launcher, but the PDT Debugger does not seem to honor breakpoints.
>>
>> I'm using the "Debug As -> PHP Web Page" action with a trivial PHP
>> script. The launcher is configured with "Break at first line" checked
>> and "Debug all pages" selected.
>>
>> I click "Resume" immediately when the PDT Debugger stops on entry to
>> the trivial PHP script, and the debugger remains active, with Eclipse
>> listening on ports 9000 and 10000.
>>
>> Later, when I run a Java client application that invokes another PHP
>> script on the same web server, the PHP engine connects to Eclipse on
>> port 9000, and the PDT Debugger stops on entry to the other PHP script.
>>
>> I can step through the PHP script with the "Step Over" and "Step Into"
>> buttons, and the "Variables" view shows all of the variables in the
>> PHP script correctly.
>>
>> I can set breakpoints in the PHP script, but they don't seem to work.
>> There are two symptoms:
>>
>> (*) When I set breakpoints in the PHP script, they appear in the
>> "Breakpoints" view with the proper file names and line numbers, but
>> the "green dot" annotation does not appear in the left border of the
>> source file editor.
>>
>> (*) When I click "Resume", the PHP script runs to completion. The PDT
>> Debugger does not stop on any of the breakpoints in the script.
>>
>> There are no messages related to this in the
>> "workspace/.metadata/.log" file. Am I missing something in my
>> configuration?
>>
>> -- Edward Pring <pring@us.ibm.com>
>
> I've done a bit more testing with a Java client application that invokes
> a PHP script, and I think I've found another problem in the PDT Debugger.
>
> My Java client application invokes the PHP script seven times,
> alternating between GET and POST, with slightly different query
> arguments each time.
>
> The PDT Debugger always stops on entry to the PHP script the first and
> second times it is invoked, but after that it misses some invocations,
> seemingly at random. For example, in successive runs of the Java client
> application, the PDT Debugger stopped on these invocations:
>
> run 1: PDT Debugger stopped on invocations 1, 2, 4, 7
> run 2: PDT Debugger stopped on invocations 1, 2, 5
> run 3: PDT Debugger stopped on invocations 1, 2, 6
>
> My Java client is correctly caching the Cookie returned in each response
> message and submitting it with the next request message, and the HTTP is
> pretty simple. A snippet of the log is attached to this message.
>
> Again, there are no messages related to this in the
> "workspace/.metadata/.log" file.
>
> Should I report this (and the missed breakpoints described above) as
> bugs? If so, is there additional diagnostic information I can collect?
>
> -- Edward Pring <pring@us.ibm.com>
>
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53507 is a reply to message #53103] |
Thu, 20 September 2007 19:32 |
Edward Pring
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
This is a multi-part message in MIME format.
--------------040708070907000506020605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Dave Kelsey wrote:
> The Web launch is not designed to work in the manner you are describing
> so there is every likelyhood that breakpoints will not work. The
> Web launch has automated path mapping which is probably what is interfering
> with breakpoints being set correctly, not sure why they don't show up in
> the editor though.
> The only way for automated path mapping to be disabled is for the
> script that is executed by the web server is the one held in your workspace
> ie your document root points to your PDT workspace.
>
> There could be many reasons why you are seeing the other problem you
> are describing. For example you can only have one web launch active and
> a web launch
> can only handle one session at a time. The previous session must end
> and be terminated before the next session tries to start otherwise it
> is ignored, one way to find out would be to have a delay between each
> invocation to allow the web launch to go through the termination process.
>
> Dave Kelsey
>
>
>>> I see. For now, I have a work-around with the existing Eclipse
>>> launcher, but the PDT Debugger does not seem to honor breakpoints.
>>>
>>> I'm using the "Debug As -> PHP Web Page" action with a trivial PHP
>>> script. The launcher is configured with "Break at first line"
>>> checked and "Debug all pages" selected.
>>>
>>> I click "Resume" immediately when the PDT Debugger stops on entry to
>>> the trivial PHP script, and the debugger remains active, with Eclipse
>>> listening on ports 9000 and 10000.
>>>
>>> Later, when I run a Java client application that invokes another PHP
>>> script on the same web server, the PHP engine connects to Eclipse on
>>> port 9000, and the PDT Debugger stops on entry to the other PHP script.
>>>
>>> I can step through the PHP script with the "Step Over" and "Step
>>> Into" buttons, and the "Variables" view shows all of the variables in
>>> the PHP script correctly.
>>>
>>> I can set breakpoints in the PHP script, but they don't seem to work.
>>> There are two symptoms:
>>>
>>> (*) When I set breakpoints in the PHP script, they appear in the
>>> "Breakpoints" view with the proper file names and line numbers, but
>>> the "green dot" annotation does not appear in the left border of the
>>> source file editor.
>>>
>>> (*) When I click "Resume", the PHP script runs to completion. The
>>> PDT Debugger does not stop on any of the breakpoints in the script.
>>>
>>> There are no messages related to this in the
>>> "workspace/.metadata/.log" file. Am I missing something in my
>>> configuration?
>>>
>>> -- Edward Pring <pring@us.ibm.com>
>>
>> I've done a bit more testing with a Java client application that invokes
>> a PHP script, and I think I've found another problem in the PDT Debugger.
>>
>> My Java client application invokes the PHP script seven times,
>> alternating between GET and POST, with slightly different query
>> arguments each time.
>>
>> The PDT Debugger always stops on entry to the PHP script the first and
>> second times it is invoked, but after that it misses some invocations,
>> seemingly at random. For example, in successive runs of the Java client
>> application, the PDT Debugger stopped on these invocations:
>>
>> run 1: PDT Debugger stopped on invocations 1, 2, 4, 7
>> run 2: PDT Debugger stopped on invocations 1, 2, 5
>> run 3: PDT Debugger stopped on invocations 1, 2, 6
>>
>> My Java client is correctly caching the Cookie returned in each response
>> message and submitting it with the next request message, and the HTTP is
>> pretty simple. A snippet of the log is attached to this message.
>>
>> Again, there are no messages related to this in the
>> "workspace/.metadata/.log" file.
>>
>> Should I report this (and the missed breakpoints described above) as
>> bugs? If so, is there additional diagnostic information I can collect?
>>
>> -- Edward Pring <pring@us.ibm.com>
>>
My web server is configured with an "alias" statement to map URLs to the
Eclipse workspace directory that contains my PHP scripts, and "Publish
files to server" is un-checked in the Run/Debug configuration that I use
to launch the PDT Debugger.
Is this enough to disable automatic path mapping in the PDT Debugger, or
do I need to make the "DocumentRoot" statement in "httpd.conf" point
directly at a PHP project directory in the Eclipse workspace?
My Java client program is single-threaded, but it has no logic between
invocations of PHP scripts, so is possible for it sometimes initiates
the next script before the PDT Debugger has terminated the previous session.
Meanwhile, I have noticed that the PDT Debugger sometimes 'hangs' when
stopping at the first line of a PHP script: After I start a Java client
application, with the PDT Debugger already running, the "Debug" view
never shows the PHP script stopped in "stepping" mode. The PDT Debugger
no longer responds after this happens.
When this happens, the Java client remains blocked, having sent an HTTP
request to Apache, waiting for an HTTP response. There is an
established TCP session between Apache and Eclipse on port 9000. When I
kill the Java client, the TCP session between Apache and Eclipse remains
established.
After I exit Eclipse, the Apache error log shows that the PHP script
really was stopped at the first line of code, although the Eclipse
"Debug" view did not show it. The Eclipse log file shows an exception
deep in the XDebug plug-in. I have attached snippets from both logs.
I have noticed this problem with both the "PDT 1.0 RC1" package (the
S20070910 build) and the "PDT 1.0" build (the R20070917 build). I have
attached a log snippet from the "PDT 1.0" build.
I appreciate that this scenario is not quite what you had in mind for
the PDT Debugger, but I think it will be valuable to make the debuggger
handle it for at least two reasons: First, because web developers
debugging PHP scripts for traditional web pages will face situations
where they cannot launch their web pages from within Eclipse. Second,
because application programmers will increasingly prefer PHP to J2EE for
implementing web services, whether with SOAP or JSON, for all the same
reasons that web developers prefer PHP to JSP and JSF.
-- Edward Pring <pring@us.ibm.com>
--------------040708070907000506020605
Content-Type: text/plain;
name="Apache-and-Eclipse-log-snippets.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Apache-and-Eclipse-log-snippets.txt"
.... snippet of Apache "logs/error.log" file ...
[Thu Sep 20 12:51:01 2007] [error] [client 127.0.0.1] PHP Fatal error: Maximum execution time of 0 seconds exceeded in C:\\eclipse\\workspace\\RecentStockTrades\\WebContent\\index .php on line 34
[Thu Sep 20 12:51:01 2007] [error] [client 127.0.0.1] PHP Stack trace:
[Thu Sep 20 12:51:01 2007] [error] [client 127.0.0.1] PHP 1. {main}() C:\\eclipse\\workspace\\RecentStockTrades\\WebContent\\index .php:0
.... snippet of Eclipse "workspace/.metadata/.log" file ...
!ENTRY org.eclipse.debug.core 4 0 2007-09-20 12:51:00.812
!MESSAGE
!STACK 0
org.osgi.framework.BundleException: Exception in org.eclipse.debug.core.DebugPlugin.stop() of bundle org.eclipse.debug.core.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.s top(BundleContextImpl.java:1056)
at org.eclipse.osgi.framework.internal.core.BundleHost.stopWork er(BundleHost.java:457)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.susp end(AbstractBundle.java:526)
at org.eclipse.osgi.framework.internal.core.Framework.suspendBu ndle(Framework.java:1148)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.d ecFWSL(StartLevelManager.java:675)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.d oSetStartLevel(StartLevelManager.java:291)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.s hutdown(StartLevelManager.java:261)
at org.eclipse.osgi.framework.internal.core.SystemBundle.suspen d(SystemBundle.java:188)
at org.eclipse.osgi.framework.internal.core.Framework.shutdown( Framework.java:622)
at org.eclipse.osgi.framework.internal.core.Framework.close(Fra mework.java:525)
at org.eclipse.osgi.framework.internal.core.OSGi.close(OSGi.jav a:41)
at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(Ecl ipseStarter.java:399)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 504)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
Caused by: org.eclipse.swt.SWTException: Widget is disposed
at org.eclipse.swt.SWT.error(SWT.java:3563)
at org.eclipse.swt.SWT.error(SWT.java:3481)
at org.eclipse.swt.SWT.error(SWT.java:3452)
at org.eclipse.swt.widgets.Display.error(Display.java:1137)
at org.eclipse.swt.widgets.Display.checkDevice(Display.java:665 )
at org.eclipse.swt.widgets.Display.getActiveShell(Display.java: 1300)
at org.eclipse.ui.internal.Workbench.getActiveWorkbenchWindow(W orkbench.java:1100)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.protocol.DBG pUtils$1.run(Unknown Source)
at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.j ava:152)
at org.eclipse.swt.widgets.Display.syncExec(Display.java:4097)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.protocol.DBG pUtils.openInternalBrowserView(Unknown Source)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTa rget.sendStopDebugURL(Unknown Source)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTa rget.terminate(Unknown Source)
at org.eclipse.debug.core.Launch.terminate(Launch.java:243)
at org.eclipse.debug.internal.core.LaunchManager.shutdown(Launc hManager.java:2234)
at org.eclipse.debug.core.DebugPlugin.stop(DebugPlugin.java:571 )
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$3 .run(BundleContextImpl.java:1040)
at java.security.AccessController.doPrivileged(AccessController .java:242)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.s top(BundleContextImpl.java:1036)
... 20 more
Root exception:
org.eclipse.swt.SWTException: Widget is disposed
at org.eclipse.swt.SWT.error(SWT.java:3563)
at org.eclipse.swt.SWT.error(SWT.java:3481)
at org.eclipse.swt.SWT.error(SWT.java:3452)
at org.eclipse.swt.widgets.Display.error(Display.java:1137)
at org.eclipse.swt.widgets.Display.checkDevice(Display.java:665 )
at org.eclipse.swt.widgets.Display.getActiveShell(Display.java: 1300)
at org.eclipse.ui.internal.Workbench.getActiveWorkbenchWindow(W orkbench.java:1100)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.protocol.DBG pUtils$1.run(Unknown Source)
at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.j ava:152)
at org.eclipse.swt.widgets.Display.syncExec(Display.java:4097)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.protocol.DBG pUtils.openInternalBrowserView(Unknown Source)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTa rget.sendStopDebugURL(Unknown Source)
at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTa rget.terminate(Unknown Source)
at org.eclipse.debug.core.Launch.terminate(Launch.java:243)
at org.eclipse.debug.internal.core.LaunchManager.shutdown(Launc hManager.java:2234)
at org.eclipse.debug.core.DebugPlugin.stop(DebugPlugin.java:571 )
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$3 .run(BundleContextImpl.java:1040)
at java.security.AccessController.doPrivileged(AccessController .java:242)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.s top(BundleContextImpl.java:1036)
at org.eclipse.osgi.framework.internal.core.BundleHost.stopWork er(BundleHost.java:457)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.susp end(AbstractBundle.java:526)
at org.eclipse.osgi.framework.internal.core.Framework.suspendBu ndle(Framework.java:1148)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.d ecFWSL(StartLevelManager.java:675)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.d oSetStartLevel(StartLevelManager.java:291)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.s hutdown(StartLevelManager.java:261)
at org.eclipse.osgi.framework.internal.core.SystemBundle.suspen d(SystemBundle.java:188)
at org.eclipse.osgi.framework.internal.core.Framework.shutdown( Framework.java:622)
at org.eclipse.osgi.framework.internal.core.Framework.close(Fra mework.java:525)
at org.eclipse.osgi.framework.internal.core.OSGi.close(OSGi.jav a:41)
at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(Ecl ipseStarter.java:399)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 504)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
--------------040708070907000506020605--
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53534 is a reply to message #53507] |
Fri, 21 September 2007 06:51 |
Eclipse User |
|
|
|
Originally posted by: dkel50.hotnospmail.com
When you launch the debugger session, the initial script that gets
launched from the provided URL must be in your workspace for path
mapping to be disabled. Once disabled, it assumes that all scripts
executed are contained within your workspace so when a break point is
set the file the breakpoint is set on is the one in your workspace. If
the web server executes the same script but is located elsewhere (ie is
a copy) then the breakpoint wont be hit because it isn't the file where
the break point is set.
Looking at your apache log the info says that your PHP script terminated
with a fatal error so that explains why your java client never gets a
response. I would expect XDebug to terminate the tcpip session it would
have started with PDT and the PDT debugger will then return to waiting
for another tcpip session to start.
The log from eclipse shows that you terminated eclipse with the web
launch still active, so it terminates that launch, at which point the
PDT debugger will send a stop URL to the browser to remove the XDebug
cookie that was set, but as it was the internal browser and the view had
already been removed, you get the widget is disposed message. You can
get around this by terminating the web launch yourself before
terminating eclipse or by using an external browser.
Dave Kelsey
Edward Pring wrote:
>
> My web server is configured with an "alias" statement to map URLs to the
> Eclipse workspace directory that contains my PHP scripts, and "Publish
> files to server" is un-checked in the Run/Debug configuration that I use
> to launch the PDT Debugger.
>
> Is this enough to disable automatic path mapping in the PDT Debugger, or
> do I need to make the "DocumentRoot" statement in "httpd.conf" point
> directly at a PHP project directory in the Eclipse workspace?
>
> My Java client program is single-threaded, but it has no logic between
> invocations of PHP scripts, so is possible for it sometimes initiates
> the next script before the PDT Debugger has terminated the previous
> session.
>
> Meanwhile, I have noticed that the PDT Debugger sometimes 'hangs' when
> stopping at the first line of a PHP script: After I start a Java client
> application, with the PDT Debugger already running, the "Debug" view
> never shows the PHP script stopped in "stepping" mode. The PDT Debugger
> no longer responds after this happens.
>
> When this happens, the Java client remains blocked, having sent an HTTP
> request to Apache, waiting for an HTTP response. There is an
> established TCP session between Apache and Eclipse on port 9000. When I
> kill the Java client, the TCP session between Apache and Eclipse remains
> established.
>
> After I exit Eclipse, the Apache error log shows that the PHP script
> really was stopped at the first line of code, although the Eclipse
> "Debug" view did not show it. The Eclipse log file shows an exception
> deep in the XDebug plug-in. I have attached snippets from both logs.
>
> I have noticed this problem with both the "PDT 1.0 RC1" package (the
> S20070910 build) and the "PDT 1.0" build (the R20070917 build). I have
> attached a log snippet from the "PDT 1.0" build.
>
> I appreciate that this scenario is not quite what you had in mind for
> the PDT Debugger, but I think it will be valuable to make the debuggger
> handle it for at least two reasons: First, because web developers
> debugging PHP scripts for traditional web pages will face situations
> where they cannot launch their web pages from within Eclipse. Second,
> because application programmers will increasingly prefer PHP to J2EE for
> implementing web services, whether with SOAP or JSON, for all the same
> reasons that web developers prefer PHP to JSP and JSF.
>
> -- Edward Pring <pring@us.ibm.com>
>
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53561 is a reply to message #53534] |
Fri, 21 September 2007 15:49 |
Edward Pring
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Dave wrote:
> When you launch the debugger session, the initial script that gets
> launched from the provided URL must be in your workspace for path
> mapping to be disabled. Once disabled, it assumes that all scripts
> executed are contained within your workspace so when a break point is
> set the file the breakpoint is set on is the one in your workspace. If
> the web server executes the same script but is located elsewhere (ie is
> a copy) then the breakpoint wont be hit because it isn't the file where
> the break point is set.
>
> Looking at your apache log the info says that your PHP script terminated
> with a fatal error so that explains why your java client never gets a
> response. I would expect XDebug to terminate the tcpip session it would
> have started with PDT and the PDT debugger will then return to waiting
> for another tcpip session to start.
>
> The log from eclipse shows that you terminated eclipse with the web
> launch still active, so it terminates that launch, at which point the
> PDT debugger will send a stop URL to the browser to remove the XDebug
> cookie that was set, but as it was the internal browser and the view had
> already been removed, you get the widget is disposed message. You can
> get around this by terminating the web launch yourself before
> terminating eclipse or by using an external browser.
>
> Dave Kelsey
>
>
> Edward Pring wrote:
>>
>> My web server is configured with an "alias" statement to map URLs to
>> the Eclipse workspace directory that contains my PHP scripts, and
>> "Publish files to server" is un-checked in the Run/Debug configuration
>> that I use to launch the PDT Debugger.
>>
>> Is this enough to disable automatic path mapping in the PDT Debugger,
>> or do I need to make the "DocumentRoot" statement in "httpd.conf"
>> point directly at a PHP project directory in the Eclipse workspace?
>>
>> My Java client program is single-threaded, but it has no logic between
>> invocations of PHP scripts, so is possible for it sometimes initiates
>> the next script before the PDT Debugger has terminated the previous
>> session.
>>
>> Meanwhile, I have noticed that the PDT Debugger sometimes 'hangs' when
>> stopping at the first line of a PHP script: After I start a Java
>> client application, with the PDT Debugger already running, the "Debug"
>> view never shows the PHP script stopped in "stepping" mode. The PDT
>> Debugger no longer responds after this happens.
>>
>> When this happens, the Java client remains blocked, having sent an
>> HTTP request to Apache, waiting for an HTTP response. There is an
>> established TCP session between Apache and Eclipse on port 9000. When
>> I kill the Java client, the TCP session between Apache and Eclipse
>> remains established.
>>
>> After I exit Eclipse, the Apache error log shows that the PHP script
>> really was stopped at the first line of code, although the Eclipse
>> "Debug" view did not show it. The Eclipse log file shows an exception
>> deep in the XDebug plug-in. I have attached snippets from both logs.
>>
>> I have noticed this problem with both the "PDT 1.0 RC1" package (the
>> S20070910 build) and the "PDT 1.0" build (the R20070917 build). I
>> have attached a log snippet from the "PDT 1.0" build.
>>
>> I appreciate that this scenario is not quite what you had in mind for
>> the PDT Debugger, but I think it will be valuable to make the
>> debuggger handle it for at least two reasons: First, because web
>> developers debugging PHP scripts for traditional web pages will face
>> situations where they cannot launch their web pages from within
>> Eclipse. Second, because application programmers will increasingly
>> prefer PHP to J2EE for implementing web services, whether with SOAP or
>> JSON, for all the same reasons that web developers prefer PHP to JSP
>> and JSF.
>>
>> -- Edward Pring <pring@us.ibm.com>
>>
Yes, Apache is executing all of my PHP scripts directly from the Eclipse
workspace (via an "Alias" statement in httpd.conf, not via
"DocumentRoot"), both the "trivial" script I use to launch the PDT
Debugger, and the "web service" script my Java client application invokes.
The "PHP Fatal Error" logged by Apache was caused by my action in
Eclipse after the PDT Debugger hung, not any error in the PHP script.
Apache's PHP engine was stopped at the first line of code in the script
(...\\index.php on line 34"), waiting for instructions from the PDT
Debugger on the TCP port 9000 session between Apache and Eclipse.
Unfortunately, the PDT Debugger was hung at that point: the Eclipse
"Debug" view did not show its usual "break at first line" call stack,
and the "step" and "resume" buttons were disabled. I eventually exited
Eclipse with the PDT Debugger still hung, causing the Eclipse exception
in the XDebug plug-in (at 12:51:00.812) and the Apache error in the PHP
engine (at 12:51:01).
I can now reproduce this hang in the PDT Debugger, and I think it is a
timing race related to ignoring a new debugging session if an old
debugging session has not quite finished terminating.
Here is a sequence of events where breakpoints work, and the PDT
Debugger does not hang:
(1) Launch the PDT Debugger with "Debug -> Web Page" using a trivial PHP
script, and click "resume" when the "Debug" view stops at the first line.
(2) Run a Java client application that invokes a "web service" PHP
script on the same Apache server. When the PDT Debugger stops in the
"Debug" view at the first line of the "web service" PHP script, set some
breakpoints in the script, and then click "resume".
(3) Whenever the PDT Debugger stops again in the "Debug" view at the
breakpoints in the "web service" script, click "resume". Eventually the
script finishes and returns an HTTP response to the Java client application.
(4) In the Java client application, after receiving the HTTP response,
wait one second, and then invoke the same "web service" PHP script on
the same Apache server again.
(5) When the PDT Debugger stops in the "Debug" view at the first line of
the "web service" script, click "resume".
(6) When the PDT Debugger stops again at the breakpoints, click "resume".
To hang the PDT Debugger, follow the same sequence of events, but
remove "wait one second" from step (4) -- that is, the Java client
application invokes the "web service" PHP script again as soon as the
first invocation finishes, without the one second delay.
The TCP port 9000 session between Apache and Eclipse is established, and
the Apache PHP engine stops at the first line of code in the "web
service" PHP script, but the Eclipse "Debug" view does not show a call
stack stopped at the first line of code. The "Debug" view shows the PDT
Debugger running, but the "step" and "resume" buttons remain disabled.
After it hangs in this way, the PDT Debugger does not respond to further
input, even after the Java client application is terminated. The only
recovery procedure I've found is to terminate the PDT Debugger, which
closes the TCP port 9000 session.
The Eclipse "workspace/.metadata/.log" file does not have any log
entries related to the hung PDT Debugger. Is there more diagnostic
information I can collect?
-- Edward Pring <pring@us.ibm.com>
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53589 is a reply to message #53561] |
Fri, 21 September 2007 16:27 |
Edward Pring
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Edward Pring wrote:
> Dave wrote:
>> When you launch the debugger session, the initial script that gets
>> launched from the provided URL must be in your workspace for path
>> mapping to be disabled. Once disabled, it assumes that all scripts
>> executed are contained within your workspace so when a break point is
>> set the file the breakpoint is set on is the one in your workspace. If
>> the web server executes the same script but is located elsewhere (ie
>> is a copy) then the breakpoint wont be hit because it isn't the file
>> where the break point is set.
>>
>> Looking at your apache log the info says that your PHP script
>> terminated with a fatal error so that explains why your java client
>> never gets a response. I would expect XDebug to terminate the tcpip
>> session it would have started with PDT and the PDT debugger will then
>> return to waiting for another tcpip session to start.
>>
>> The log from eclipse shows that you terminated eclipse with the web
>> launch still active, so it terminates that launch, at which point the
>> PDT debugger will send a stop URL to the browser to remove the XDebug
>> cookie that was set, but as it was the internal browser and the view
>> had already been removed, you get the widget is disposed message. You
>> can get around this by terminating the web launch yourself before
>> terminating eclipse or by using an external browser.
>>
>> Dave Kelsey
>>
>>
>> Edward Pring wrote:
>>>
>>> My web server is configured with an "alias" statement to map URLs to
>>> the Eclipse workspace directory that contains my PHP scripts, and
>>> "Publish files to server" is un-checked in the Run/Debug
>>> configuration that I use to launch the PDT Debugger.
>>>
>>> Is this enough to disable automatic path mapping in the PDT Debugger,
>>> or do I need to make the "DocumentRoot" statement in "httpd.conf"
>>> point directly at a PHP project directory in the Eclipse workspace?
>>>
>>> My Java client program is single-threaded, but it has no logic
>>> between invocations of PHP scripts, so is possible for it sometimes
>>> initiates the next script before the PDT Debugger has terminated the
>>> previous session.
>>>
>>> Meanwhile, I have noticed that the PDT Debugger sometimes 'hangs'
>>> when stopping at the first line of a PHP script: After I start a Java
>>> client application, with the PDT Debugger already running, the
>>> "Debug" view never shows the PHP script stopped in "stepping" mode.
>>> The PDT Debugger no longer responds after this happens.
>>>
>>> When this happens, the Java client remains blocked, having sent an
>>> HTTP request to Apache, waiting for an HTTP response. There is an
>>> established TCP session between Apache and Eclipse on port 9000.
>>> When I kill the Java client, the TCP session between Apache and
>>> Eclipse remains established.
>>>
>>> After I exit Eclipse, the Apache error log shows that the PHP script
>>> really was stopped at the first line of code, although the Eclipse
>>> "Debug" view did not show it. The Eclipse log file shows an
>>> exception deep in the XDebug plug-in. I have attached snippets from
>>> both logs.
>>>
>>> I have noticed this problem with both the "PDT 1.0 RC1" package (the
>>> S20070910 build) and the "PDT 1.0" build (the R20070917 build). I
>>> have attached a log snippet from the "PDT 1.0" build.
>>>
>>> I appreciate that this scenario is not quite what you had in mind for
>>> the PDT Debugger, but I think it will be valuable to make the
>>> debuggger handle it for at least two reasons: First, because web
>>> developers debugging PHP scripts for traditional web pages will face
>>> situations where they cannot launch their web pages from within
>>> Eclipse. Second, because application programmers will increasingly
>>> prefer PHP to J2EE for implementing web services, whether with SOAP
>>> or JSON, for all the same reasons that web developers prefer PHP to
>>> JSP and JSF.
>>>
>>> -- Edward Pring <pring@us.ibm.com>
>>>
>
> Yes, Apache is executing all of my PHP scripts directly from the Eclipse
> workspace (via an "Alias" statement in httpd.conf, not via
> "DocumentRoot"), both the "trivial" script I use to launch the PDT
> Debugger, and the "web service" script my Java client application invokes.
>
> The "PHP Fatal Error" logged by Apache was caused by my action in
> Eclipse after the PDT Debugger hung, not any error in the PHP script.
> Apache's PHP engine was stopped at the first line of code in the script
> (...\\index.php on line 34"), waiting for instructions from the PDT
> Debugger on the TCP port 9000 session between Apache and Eclipse.
> Unfortunately, the PDT Debugger was hung at that point: the Eclipse
> "Debug" view did not show its usual "break at first line" call stack,
> and the "step" and "resume" buttons were disabled. I eventually exited
> Eclipse with the PDT Debugger still hung, causing the Eclipse exception
> in the XDebug plug-in (at 12:51:00.812) and the Apache error in the PHP
> engine (at 12:51:01).
>
> I can now reproduce this hang in the PDT Debugger, and I think it is a
> timing race related to ignoring a new debugging session if an old
> debugging session has not quite finished terminating.
>
> Here is a sequence of events where breakpoints work, and the PDT
> Debugger does not hang:
>
> (1) Launch the PDT Debugger with "Debug -> Web Page" using a trivial PHP
> script, and click "resume" when the "Debug" view stops at the first line.
>
> (2) Run a Java client application that invokes a "web service" PHP
> script on the same Apache server. When the PDT Debugger stops in the
> "Debug" view at the first line of the "web service" PHP script, set some
> breakpoints in the script, and then click "resume".
>
> (3) Whenever the PDT Debugger stops again in the "Debug" view at the
> breakpoints in the "web service" script, click "resume". Eventually the
> script finishes and returns an HTTP response to the Java client
> application.
>
> (4) In the Java client application, after receiving the HTTP response,
> wait one second, and then invoke the same "web service" PHP script on
> the same Apache server again.
>
> (5) When the PDT Debugger stops in the "Debug" view at the first line of
> the "web service" script, click "resume".
>
> (6) When the PDT Debugger stops again at the breakpoints, click "resume".
>
> To hang the PDT Debugger, follow the same sequence of events, but
> remove "wait one second" from step (4) -- that is, the Java client
> application invokes the "web service" PHP script again as soon as the
> first invocation finishes, without the one second delay.
>
> The TCP port 9000 session between Apache and Eclipse is established, and
> the Apache PHP engine stops at the first line of code in the "web
> service" PHP script, but the Eclipse "Debug" view does not show a call
> stack stopped at the first line of code. The "Debug" view shows the PDT
> Debugger running, but the "step" and "resume" buttons remain disabled.
>
> After it hangs in this way, the PDT Debugger does not respond to further
> input, even after the Java client application is terminated. The only
> recovery procedure I've found is to terminate the PDT Debugger, which
> closes the TCP port 9000 session.
>
> The Eclipse "workspace/.metadata/.log" file does not have any log
> entries related to the hung PDT Debugger. Is there more diagnostic
> information I can collect?
>
> -- Edward Pring <pring@us.ibm.com>
>
>
Sorry -- I mis-spoke near the end of the previous message. I meant to say:
After the PDT Debugger hangs in this way, it does not respond to further
input, even after the Java client application is terminated. The only
recovery procedure I've found is to terminate Eclipse, which closes the
TCP port 9000 session with Apache. If the PDT Debugger is terminated,
and then launched again in the same Eclipse session, the new instance of
the PDT Debugger hangs immediately when Apache connects to port 9000.
-- Edward Pring <pring@us.ibm.com>
|
|
|
| Re: how to start and XDebug session in PDT Debugger without launching a browser? [message #53617 is a reply to message #53589] |
Fri, 21 September 2007 18:52 |
| Eclipse User |
|
|
|
Originally posted by: dkel50.hotnospmail.com
Edward Pring wrote:
> Edward Pring wrote:
>> Dave wrote:
>>> When you launch the debugger session, the initial script that gets
>>> launched from the provided URL must be in your workspace for path
>>> mapping to be disabled. Once disabled, it assumes that all scripts
>>> executed are contained within your workspace so when a break point is
>>> set the file the breakpoint is set on is the one in your workspace.
>>> If the web server executes the same script but is located elsewhere
>>> (ie is a copy) then the breakpoint wont be hit because it isn't the
>>> file where the break point is set.
>>>
>>> Looking at your apache log the info says that your PHP script
>>> terminated with a fatal error so that explains why your java client
>>> never gets a response. I would expect XDebug to terminate the tcpip
>>> session it would have started with PDT and the PDT debugger will then
>>> return to waiting for another tcpip session to start.
>>>
>>> The log from eclipse shows that you terminated eclipse with the web
>>> launch still active, so it terminates that launch, at which point the
>>> PDT debugger will send a stop URL to the browser to remove the XDebug
>>> cookie that was set, but as it was the internal browser and the view
>>> had already been removed, you get the widget is disposed message. You
>>> can get around this by terminating the web launch yourself before
>>> terminating eclipse or by using an external browser.
>>>
>>> Dave Kelsey
>>>
>>>
>>> Edward Pring wrote:
>>>>
>>>> My web server is configured with an "alias" statement to map URLs to
>>>> the Eclipse workspace directory that contains my PHP scripts, and
>>>> "Publish files to server" is un-checked in the Run/Debug
>>>> configuration that I use to launch the PDT Debugger.
>>>>
>>>> Is this enough to disable automatic path mapping in the PDT
>>>> Debugger, or do I need to make the "DocumentRoot" statement in
>>>> "httpd.conf" point directly at a PHP project directory in the
>>>> Eclipse workspace?
>>>>
>>>> My Java client program is single-threaded, but it has no logic
>>>> between invocations of PHP scripts, so is possible for it sometimes
>>>> initiates the next script before the PDT Debugger has terminated the
>>>> previous session.
>>>>
>>>> Meanwhile, I have noticed that the PDT Debugger sometimes 'hangs'
>>>> when stopping at the first line of a PHP script: After I start a
>>>> Java client application, with the PDT Debugger already running, the
>>>> "Debug" view never shows the PHP script stopped in "stepping" mode.
>>>> The PDT Debugger no longer responds after this happens.
>>>>
>>>> When this happens, the Java client remains blocked, having sent an
>>>> HTTP request to Apache, waiting for an HTTP response. There is an
>>>> established TCP session between Apache and Eclipse on port 9000.
>>>> When I kill the Java client, the TCP session between Apache and
>>>> Eclipse remains established.
>>>>
>>>> After I exit Eclipse, the Apache error log shows that the PHP script
>>>> really was stopped at the first line of code, although the Eclipse
>>>> "Debug" view did not show it. The Eclipse log file shows an
>>>> exception deep in the XDebug plug-in. I have attached snippets from
>>>> both logs.
>>>>
>>>> I have noticed this problem with both the "PDT 1.0 RC1" package (the
>>>> S20070910 build) and the "PDT 1.0" build (the R20070917 build). I
>>>> have attached a log snippet from the "PDT 1.0" build.
>>>>
>>>> I appreciate that this scenario is not quite what you had in mind
>>>> for the PDT Debugger, but I think it will be valuable to make the
>>>> debuggger handle it for at least two reasons: First, because web
>>>> developers debugging PHP scripts for traditional web pages will face
>>>> situations where they cannot launch their web pages from within
>>>> Eclipse. Second, because application programmers will increasingly
>>>> prefer PHP to J2EE for implementing web services, whether with SOAP
>>>> or JSON, for all the same reasons that web developers prefer PHP to
>>>> JSP and JSF.
>>>>
>>>> -- Edward Pring <pring@us.ibm.com>
>>>>
>>
>> Yes, Apache is executing all of my PHP scripts directly from the
>> Eclipse workspace (via an "Alias" statement in httpd.conf, not via
>> "DocumentRoot"), both the "trivial" script I use to launch the PDT
>> Debugger, and the "web service" script my Java client application
>> invokes.
>>
>> The "PHP Fatal Error" logged by Apache was caused by my action in
>> Eclipse after the PDT Debugger hung, not any error in the PHP script.
>> Apache's PHP engine was stopped at the first line of code in the
>> script (...\\index.php on line 34"), waiting for instructions from the
>> PDT Debugger on the TCP port 9000 session between Apache and Eclipse.
>> Unfortunately, the PDT Debugger was hung at that point: the Eclipse
>> "Debug" view did not show its usual "break at first line" call stack,
>> and the "step" and "resume" buttons were disabled. I eventually
>> exited Eclipse with the PDT Debugger still hung, causing the Eclipse
>> exception in the XDebug plug-in (at 12:51:00.812) and the Apache error
>> in the PHP engine (at 12:51:01).
>>
>> I can now reproduce this hang in the PDT Debugger, and I think it is a
>> timing race related to ignoring a new debugging session if an old
>> debugging session has not quite finished terminating.
>>
>> Here is a sequence of events where breakpoints work, and the PDT
>> Debugger does not hang:
>>
>> (1) Launch the PDT Debugger with "Debug -> Web Page" using a trivial
>> PHP script, and click "resume" when the "Debug" view stops at the
>> first line.
>>
>> (2) Run a Java client application that invokes a "web service" PHP
>> script on the same Apache server. When the PDT Debugger stops in the
>> "Debug" view at the first line of the "web service" PHP script, set
>> some breakpoints in the script, and then click "resume".
>>
>> (3) Whenever the PDT Debugger stops again in the "Debug" view at the
>> breakpoints in the "web service" script, click "resume". Eventually
>> the script finishes and returns an HTTP response to the Java client
>> application.
>>
>> (4) In the Java client application, after receiving the HTTP response,
>> wait one second, and then invoke the same "web service" PHP script on
>> the same Apache server again.
>>
>> (5) When the PDT Debugger stops in the "Debug" view at the first line
>> of the "web service" script, click "resume".
>>
>> (6) When the PDT Debugger stops again at the breakpoints, click "resume".
>>
>> To hang the PDT Debugger, follow the same sequence of events, but
>> remove "wait one second" from step (4) -- that is, the Java client
>> application invokes the "web service" PHP script again as soon as the
>> first invocation finishes, without the one second delay.
>>
>> The TCP port 9000 session between Apache and Eclipse is established,
>> and the Apache PHP engine stops at the first line of code in the "web
>> service" PHP script, but the Eclipse "Debug" view does not show a call
>> stack stopped at the first line of code. The "Debug" view shows the
>> PDT Debugger running, but the "step" and "resume" buttons remain
>> disabled.
>>
>> After it hangs in this way, the PDT Debugger does not respond to
>> further input, even after the Java client application is terminated.
>> The only recovery procedure I've found is to terminate the PDT
>> Debugger, which closes the TCP port 9000 session.
>>
>> The Eclipse "workspace/.metadata/.log" file does not have any log
>> entries related to the hung PDT Debugger. Is there more diagnostic
>> information I can collect?
>>
>> -- Edward Pring <pring@us.ibm.com>
>>
>>
> Sorry -- I mis-spoke near the end of the previous message. I meant to say:
>
> After the PDT Debugger hangs in this way, it does not respond to further
> input, even after the Java client application is terminated. The only
> recovery procedure I've found is to terminate Eclipse, which closes the
> TCP port 9000 session with Apache. If the PDT Debugger is terminated,
> and then launched again in the same Eclipse session, the new instance of
> the PDT Debugger hangs immediately when Apache connects to port 9000.
>
> -- Edward Pring <pring@us.ibm.com>
It sounds like the Web Launch has not hung, but is waiting for the next
session to come in. All you can do with the web launch once a debug
session has terminated is stop it. It is waiting for another connection
from xdebug. Why when another session comes in and the debugger is
waiting for one and it appears to hang again, that I don't know. PDT is
always listening for sessions on the XDebug port.
Dave Kelsey
|
|
|
Goto Forum:
Current Time: Sun Sep 01 06:04:34 GMT 2024
Powered by FUDForum. Page generated in 0.03789 seconds |
] 
Search
Help
Register
Login
Home
