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:



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:



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



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



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?

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

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:



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:


then i changed it to be:


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".



however, i still got the same problem which made me quite frustrated. Dmitri, any help from your side is highly appreciated!

cgi_handler is what dbg-cli runs. It may not be xx.php file iself, but php binary.



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


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.

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


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.

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
I thought readme is clear enough...