NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
is dbg-cli actually working on linux? *resolved*


Joined: 30 Mar 2006
Posts: 8
Reply with quote
i don't know if it is approriate to post dbg-cli questions here, as it is not part of the supported phped.

just built and installed both dbg-cli and dbg extension 2.13.1 (with php 5.1.12) on linux from: http://www.php-debugger.com/dbg/downloads.php

here is my dbg module's config:

Code:

debugger.enable_session_cookie => On => On
debugger.enabled => On => On
debugger.fail_silently => Off => Off
debugger.ignore_nops => Off => Off
debugger.JIT_enabled => On => On
debugger.JIT_host => localhost => localhost
debugger.JIT_level => 3 => 3
debugger.JIT_port => 10001 => 10001
debugger.profiler_enabled => Off => Off
debugger.session_nocache => On => On
debugger.timeout_seconds => 300 => 300


when i run dbg-cli, i always get this timeout error: "Session start timeout has expired."

i am assuming dbg-cli starts a listener thread (by default, listening on localhost:10001) and then forks php executable, and dbg module in php tries to connect to it.

when i tried to debug it, i found that when php is spawned by dbg-cli, it never tried to initiating a connection to localhost:10001, and that's the reason of timeout error. here is the debug output:

Code:

module init
dbg_startup Zend extension
TS_ALLOC_CTOR_FUNCTION(DBG)
php_dbg_clearruntimeglobals
dbg_activate Zend extension
RINIT q='(null)'
chk_session_request NULL
chk_scan_post '_POST'
chk_scan_post 'HTTP_POST_VARS'
chk_scan_post '_COOKIE'
chk_scan_post 'HTTP_COOKIE_VARS'
chk_session_request NULL
RINIT isreq='0'
dbg_op_array_ctor
dbg_op_array_handler -:(null)
dbg_op_array_dtor
PHP_RSHUTDOWN_FUNCTION
module_cleanup
socket = (0)
php_dbg_clearruntimeglobals
dbg_deactivate Zend extension
TS_ALLOC_DTOR_FUNCTION
module_cleanup
socket = (0)
php_dbg_clearruntimeglobals
module shutdown
dbg_shutdown Zend extension


however, if i start php from the command line, dbg module does try to connect to localhost:10001 and here is the log:

Code:

module init
dbg_startup Zend extension
TS_ALLOC_CTOR_FUNCTION(DBG)
php_dbg_clearruntimeglobals
dbg_activate Zend extension
RINIT q='(null)'
chk_session_request NULL
chk_scan_post '_POST'
chk_scan_post 'HTTP_POST_VARS'
chk_scan_post '_COOKIE'
chk_scan_post 'HTTP_COOKIE_VARS'
chk_session_request NULL
RINIT isreq='0'
dbg_op_array_ctor
dbg_op_array_handler /home/xwang/test.php:(null)
begin fcall function:(null) file:/home/xwang/test.php:3
exit fcall
debugbreak()
dbg_start_session req 4
create_debugger_socket(4)
address(localhost)
dbg_lookup_hostname
conn. allowed to localhost:10001
OSERR: 111 "connect() failed
"
end fcall function:(null) file:/home/xwang/test.php:3
dbg_op_array_dtor
PHP_RSHUTDOWN_FUNCTION
module_cleanup
client_address = 842528c
socket = (-3)
php_dbg_clearruntimeglobals
dbg_deactivate Zend extension
TS_ALLOC_DTOR_FUNCTION
module_cleanup
socket = (0)
php_dbg_clearruntimeglobals
module shutdown
dbg_shutdown Zend extension


then i checked the code which shows dbg-cli doesn't pass the argument (which is the script file name) to execve():

Code:

file DbgSpawn.cpp:84
execve(filename, NULL, env);


looks like dbg-cli doesn't work at all which is obviously impossible. i am confused, or did i do anything wrong? what is dbg-cli supposed to do?
View user's profileFind all posts by javaperlSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 7861
Reply with quote
First of all, before blaming dbg-cli, please understand that it's a free product and if you need a commercial-quality one, take a look at NuSphere PhpED that uses DBG quite successfully.
Regarding the "problem", in what mode do you run dbg-cli? By default it runs in CGI mode which means that it should execute php and pass CGI variables to it. No arguments are to be passed. Never. That's why execve contains NULL as a 2nd argument.
If you want to debug with HTTP server running php, you need to set this mode. Just read README first.
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 30 Mar 2006
Posts: 8
Reply with quote
ddmitrie wrote:
First of all, before blaming dbg-cli, please understand that it's a free product and if you need a commercial-quality one, take a look at NuSphere PhpED that uses DBG quite successfully.
Regarding the "problem", in what mode do you run dbg-cli? By default it runs in CGI mode which means that it should execute php and pass CGI variables to it. No arguments are to be passed. Never. That's why execve contains NULL as a 2nd argument.
If you want to debug with HTTP server running php, you need to set this mode. Just read README first.


sorry if i have any words offending you! dbg is a great one and that's what i heard from many friends and that's why i am trying it. i guess all people here appreciate your hard work to bring both free and commercial products to us. what frustrated me is that i was never able to let it work. i understand it must be a problem on my side.

yes, i am using the CGI mode (could you double check if i have anything set up wrong in my dbg module config of my previous post?). i checked the env before spawning php cgi and looks like it has the right script in it. what could be wrong?
View user's profileFind all posts by javaperlSend private message


Joined: 30 Mar 2006
Posts: 8
Reply with quote
javaperl wrote:
ddmitrie wrote:
First of all, before blaming dbg-cli, please understand that it's a free product and if you need a commercial-quality one, take a look at NuSphere PhpED that uses DBG quite successfully.
Regarding the "problem", in what mode do you run dbg-cli? By default it runs in CGI mode which means that it should execute php and pass CGI variables to it. No arguments are to be passed. Never. That's why execve contains NULL as a 2nd argument.
If you want to debug with HTTP server running php, you need to set this mode. Just read README first.


sorry if i have any words offending you! dbg is a great one and that's what i heard from many friends and that's why i am trying it. i guess all people here appreciate your hard work to bring both free and commercial products to us. what frustrated me is that i was never able to let it work. i understand it must be a problem on my side.

yes, i am using the CGI mode (could you double check if i have anything set up wrong in my dbg module config of my previous post?). i checked the env before spawning php cgi and looks like it has the right script in it. what could be wrong?


more info. in my case, looks like the dbg module's dbg_start_session() (which calls create_debugger_socket()/connect()) is never called. what triggers dbg module to call that function? any input from you is highly appreciated!
View user's profileFind all posts by javaperlSend private message


Joined: 30 Mar 2006
Posts: 8
Reply with quote
javaperl wrote:
javaperl wrote:
ddmitrie wrote:
First of all, before blaming dbg-cli, please understand that it's a free product and if you need a commercial-quality one, take a look at NuSphere PhpED that uses DBG quite successfully.
Regarding the "problem", in what mode do you run dbg-cli? By default it runs in CGI mode which means that it should execute php and pass CGI variables to it. No arguments are to be passed. Never. That's why execve contains NULL as a 2nd argument.
If you want to debug with HTTP server running php, you need to set this mode. Just read README first.


sorry if i have any words offending you! dbg is a great one and that's what i heard from many friends and that's why i am trying it. i guess all people here appreciate your hard work to bring both free and commercial products to us. what frustrated me is that i was never able to let it work. i understand it must be a problem on my side.

yes, i am using the CGI mode (could you double check if i have anything set up wrong in my dbg module config of my previous post?). i checked the env before spawning php cgi and looks like it has the right script in it. what could be wrong?


more info. in my case, looks like the dbg module's dbg_start_session() (which calls create_debugger_socket()/connect()) is never called. what triggers dbg module to call that function? any input from you is highly appreciated!


is this topic talking about the same issue? what does it mean? how can i fix it? thanks!
local-debugger-session-t1443.html
View user's profileFind all posts by javaperlSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 7861
Reply with quote
Looks like this post is related to the problem:
php-cli-script-debugging-with-dbg-cli-t1672.html
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 30 Mar 2006
Posts: 8
Reply with quote
ddmitrie wrote:
Looks like this post is related to the problem:
php-cli-script-debugging-with-dbg-cli-t1672.html


i guess my problem is the same as the above post. so i dumped out my env here:

Code:

REDIRECT_QUERY_STRING
REDIRECT_STATUS=200
REDIRECT_URL=/home/xwang/test.php
SERVER_SOFTWARE=DBG/2.1
SERVER_NAME=localhost
SERVER_ADDR=127.0.0.1
SERVER_PORT=80
REMOTE_ADDR=127.0.0.1
SCRIPT_FILENAME=php
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
REQUEST_METHOD=GET
QUERY_STRING
REQUEST_URI=/home/xwang/test.php
PATH_INFO=/home/xwang/test.php
PATH_TRANSLATED=/home/xwang/test.php
HTTP_COOKIE=DBGSESSID=11439636363807700001@clienthost:10001


notice the SCRIPT_FILENAME is also set to "php" which is the executable of my php. my impression is that SCRIPT_FILENAME should be set to be the actually php script which should be "/home/xwang/test.php" in my case. then I checked dbg-cli source and found this line sets it:

command.cpp:678:
Code:

sessionreq.cgi_handler=cgihandler;


then i changed it to be:
Code:

sessionreq.cgi_handler=main_script;


here is the env i dumped out after i made the change. notice this time SCRIPT_FILENAME is set to be "/home/xwang/test.php".

Code:

REDIRECT_QUERY_STRING
REDIRECT_STATUS=200
REDIRECT_URL=/home/xwang/test.php
SERVER_SOFTWARE=DBG/2.1
SERVER_NAME=localhost
SERVER_ADDR=127.0.0.1
SERVER_PORT=80
REMOTE_ADDR=127.0.0.1
SCRIPT_FILENAME=/home/xwang/test.php
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
REQUEST_METHOD=GET
QUERY_STRING
REQUEST_URI=/home/xwang/test.php
PATH_INFO=/home/xwang/test.php
PATH_TRANSLATED=/home/xwang/test.php
HTTP_COOKIE=DBGSESSID=11439661100590560001@clienthost:10001


however, i still got the same problem which made me quite frustrated. Dmitri, any help from your side is highly appreciated!
View user's profileFind all posts by javaperlSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 7861
Reply with quote
cgi_handler is what dbg-cli runs. It may not be xx.php file iself, but php binary.

Quote:
i guess my problem is the same as the above post


so it will be resolved if you specify set port 7869 command.

Quote:
Regarding SCRIPT_FILENAME=php

I'd recommend you to try php under Apache as CGI, not as apache module and compare the results.

BTW, is php binary in $PATH? If not, I'd expect full path to it instead.
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 30 Mar 2006
Posts: 8
Reply with quote
ddmitrie wrote:
cgi_handler is what dbg-cli runs. It may not be xx.php file iself, but php binary.

Quote:
i guess my problem is the same as the above post


so it will be resolved if you specify set port 7869 command.

Quote:
Regarding SCRIPT_FILENAME=php

I'd recommend you to try php under Apache as CGI, not as apache module and compare the results.

BTW, is php binary in $PATH? If not, I'd expect full path to it instead.


thanks a lot for continuously helping me to resolve this issue! my php is in the $PATH. i tried with the full path, but the same result.

let me try what you suggested.
View user's profileFind all posts by javaperlSend private message


Joined: 30 Mar 2006
Posts: 8
Reply with quote
after spending hours of extensive debugging in dbg-cli, dbg module, and php, finally the my problems were found!

1. dbg-cli timeout issue.
command.cpp:697
Code:

        //sessionreq.timeoutms_waitsess = 10000;
        //sessionreq.timeoutms_client = 30000;
        sessionreq.timeoutms_waitsess = 1000000;
        sessionreq.timeoutms_client = 3000000;


i changed both of them to have much longer timeouts. in my environment, i don't know why the current timeouts are too short for waiting the initial connection from dbg module. it seems to take a few seconds for the dbg module to reach from "dbg_startup Zend extension" to "TS_ALLOC_CTOR_FUNCTION(DBG)" which is barely not faster enough for the current timeouts. my machine is a pentinum 4 1.5G mem which should be a good one. when i have a chance, i will try to debug what takes the unsual time.

2. when running dbg-cli with standalone php cgi, we HAVE TO specify the full path of the script that to be run (for example, /my/path/to/mytest.php), even when mytest.php exists in the current working directory. in php's cgi_main.c:1683, it requires the "SG(request_info).path_translated" to be a full path file name.

Dmitri, when you have a chance, could you please make dbg-cli's timeouts to be configurable and also the default timeouts to be longer? it would be nicer to find out why it takes dbg module some time to initiate the connection.

it would be nice to address issue #2 in dbg-cli's readme file.

thanks much for sticking with me for this issue! i bet many people suffered the same problems and it is nice to find out why.
View user's profileFind all posts by javaperlSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 7861
Reply with quote
The default timeout of 10seconds looked good to me. Does your php take longer to start up a request?

Regarding full path to the script, it's surely required because php binary itself is not in the current directory Smile
I thought readme is clear enough...
View user's profileFind all posts by dmitriSend private messageVisit poster's website
is dbg-cli actually working on linux? *resolved*
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 1 of 1  

  
  
 Reply to topic