wrong.
In HTTP mode:
Browser connects to the server, server runs php engine to process php script, dbg.so intercepts execution and connects back to the client (it supposes that dbglistnener or dbg-cli is waiting for connection), dbglistener informs the IDE that debug session started and so forth.
In CGI(direct) mode:
dbg-cli (or dbglistner) runs php executable supplying php script, php executable loads php extensions (and dbg), dbg intercepts execution and so forth with the same scenario as above.

Any further questions ?

[quote="ddmitrie"]


*sigh* I meant:

*server* (not browser) gets connection, dbg.so intercepts it, dbglistener picks up connection from dbg.so. which is basically what you said. (sorry, I was tired).

If what you say is true, I should be able to get the effect I want from
setting an infinite timeout in dbg-cli - and submitting stuff through the browser. Right? although I can't figure out why you need to manually set the http root, etc. inside of dbg-cli before you do this.

Anyway, I must be doing something exceedingly stupid. I've tried dbg.so on *both* solaris and linux, and have gotten the same timeout error, even though it looks like (through phpinfo()) that everything is loaded correctly. I'm assuming you've tested it recently on linux, so it must be an error on my side. A very annoying error.

Anyways, I'm going to trace through this via brute force if necessary. Either I'm doing something wrong, there's a missing step in the documentation, or both. And its bugging the hell out of me.

well, you can enable logging for both dbg-cli and dbg.so.
1. Open deferphpize in the editor, locate ./configure call and add --with-dbg-trace argument then recompile dbg.so
2. chdir to dbg-cli, run make clean, then run configure with --with-dbgtrace --with-dbg-trace=/tmp/dbgbase.log
try to run debug session then send me both /tmp/dbgbase.log and /tmp/dbg.log


that's becaure dbg-cli works with local sources (files on the local computer) and therefore it needs to know where to take the files from. For example when dbg.so tells that it is running /var/www/mydir/myfile.php, dbg-cli should extract remote root (which in this case should be something like /var/www) from the path and add local project root to it. If you have local root in /home/aaa/www, the full path to the file would become /home/aaa/www/mydir/myfile.php
Regarding http root, it's clear too. By supplying httproot as http://myserver/
you let dbg-cli know what URL should be run when you launch run /home/aaa/www/mydir/myfile.php command. In this case local root will be stripped off and httproot added so the resulting url will be http://myserver/mydir/myfile.php.