when I run dbg-cli and even just load a file with

dbg> file myfile.php
dbg> run
dbg> step

I get the dreaded timeout error. 'Session start timeout has expired'.

why is this? How is just running dbg-cli tied into port 7869, or port 10001 for that matter? If I do 'php-info' I get:

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

and no changing of JIT_enabled, or the host (to either localhost or IP), or whatever helps..

(ps -

when running netstat, I *do* see a port 10001 being created when dbg.so is run. However, when the call gets to

ret_val = select(listen_socket + 1, &rset , NULL, NULL, &timeout)

in dbgbase/dbgbase_globals.cpp, it times out.

so - I'm doubly confused. where does the listener fit in? And why isn't the select binding my socket when 10001 is being created?

I'm running solaris here, so porting might be an issue.. this sure looks like a bug in dbg-cli though.. any help would be appreciated in tracking this down. My email address is

esp5@pge.com

and I could use the help. I'm sure dbg-cli is great to use, just need to get it to work..

Thanks in advance,

Ed

the settings shown above are related to JIT debugging which is not available with dbg-cli. JIT is a way to start debug session when an error happened in php code, for example if your script produced E_ERROR it will cause dbg.so to activate debug session with host/port entered in the settings if JIT_enabled is On of course. This functionality requires dbglistener to listen permanently on the client part and only dbglistener supports it, not dbg-cli. Hope it explains why 7869 was not used as might expected .
For the rest cases it is client parts decides what TCP port to use for debug sessions. By default dbg-cli uses 10001, but it can be changed. See SET/SHOW PORT commands.

[quote="ddmitrie"]

ok, that's cool, but it still doesn't explain why its creating a socket and not binding to it (and timing out). No matter what port I use, this happens - I've got everything set up correctly as far as I can see, and it actually is the socket call that is failing. I even run it as sudo, with no go..

If you need any diagnostic output to help track this down, I'd be more than willing to give it.

Not sure what you mean.
Take a look at dbgbase/dbgbase_globals.cpp:629

it certainly binds...
then listens
dbgbase/dbgbase_globals.cpp:634:

then accepts
dbgbase/dbgbase_globals.cpp:665:

cool.. but then why does the select fail? Any ideas?

hmm, it works under linux pretty well...
BTW, did you install readline library to compile dbg-cli under SunOS ?