PHP IDE :: NuSphere Forums :: View topic - PHP-CLI script debugging with dbg-cli

Posted: Tue Nov 01, 2005 6:20 pm

Hi All,

First I want to say thanks for such a wonderful tool. I have been using dbg to debug apache based php and it works great!

I am working on a purely php-cli based project and would like to use dbg-cli to debug it. Reading through the postings here, there have been others struggling to get dbg-cli to connect. I have tried all the suggestions and have not been able to get this thing to connect. So here is my setup:

php version 4.4.0 (cli)
dbg version 2.11.32
dbg-cli version 2.11.32

php.ini contains:

Code:

extension=dbg.so
[debugger]
debugger.enabled=on
debugger.profiler_enabled=on
debugger.JIT_host = localhost
debugger.JIT_port = 7869
debugger.fail_silently = Off

php -i includes the following section:

Code:

dbg

<TABLE BORDER=1 CELLPADDING=3 CELLSPACING=0 WIDTH=600 BGCOLOR=#33CCFF ALIGN="CENTER"><TR VALIGN='MIDDLE' ALIGN='CENTER'><TD><B><A HREF='http://www.nusphere.com/dbg' STYLE='color: #660880; background-color: #33CCFF'>DBG php debugger, version 2.11.32, Copyright 2001, 2005, Dmitri Dmitrienko, www.nusphere.com</A></B></TD></TR></TABLE><BR>

Version => 2.11.32
Linked => as a shared library.
Profiler => compiled, enabled

Directive => Local Value => Master Value
debugger.enable_session_cookie => On => On
debugger.enabled => On => On
debugger.fail_silently => Off => Off
debugger.ignore_nops => Off => Off
debugger.JIT_enabled => Off => Off
debugger.JIT_host => localhost => localhost
debugger.JIT_level => 3 => 3
debugger.JIT_port => 7870 => 7870
debugger.profiler_enabled => On => On
debugger.session_nocache => On => On
debugger.timeout_seconds => 300 => 300

Running dbg-cli I get:

Code:

$ dbg-cli
ListenerBase::ListenerBase
DBG php debugger, version 2.11.32, Copyright 2001, 2005, Dmitri Dmitrienko, www.nusphere.com
[DBG] parse_args(argc=1, argv=(null))
dbg>set mode off
[DBG] set mode->0 (off)dbg>set cgiexec php
dbg>show cgiexec
/usr/bin/php.
dbg> set port 7869
dbg> file test.php
Reading symbols from test.php...done.
dbg> run
ListenerBase::startsession
ThreadBase::ThreadBase
dbh_create_listen_socket(, 7869)
socket=3
open_dbg_session
open_cgi_session
olddir=/home/pellja/projects/tagnet
path=/usr/bin
open_cgi_session -> pid=28061 OK
ThreadBase::close()

Program exited.
Session start timeout has expired.
Program is not being run.
dbg>quit
ListenerBase::~ListenerBase
ListenerBase::stop
ListenerBase::stopJIT
stopping clients

The dbgbase.log file seems to be included in the session output so I won't include that. I have tried telneting in to the port and find nothing listening. A "tcpdump host localhost" doesn't return anything. I had debugger.JIT_host = clienthost but that made no difference. It is strange because I have been using the mod_php version with apache with no problems. Any help would be very much appreciated! I am happy to dig into the code if need be. I need this thing to work Smile

Cheers,

James Pellow

Posted: Wed Nov 02, 2005 5:29 am

it's my understanding that you've compiled dbg-cli with debug logging enabled.

Quote:

open_cgi_session -> pid=28061 OK

it means that at least child process with php was forked.
please try to do the following
using dbg-cli run a script that either intercepts phpinfo() output and saves it into a file or anyhow checks that dbg extension is loaded and enabled.
I think there is a problem with this.

Also, it may help to provide full path to php when your run set cgiexec php

Posted: Wed Nov 02, 2005 11:01 am

Thanks for your reply. Here are the results of that test. First the php script I ran with the debugger:

Code:

<?php
if (extension_loaded('dbg')) {
$funcs = get_extension_funcs('dbg');
print_r($funcs);
$f = fopen('/home/pellja/projects/tagnet/output.txt', 'w');
foreach ($funcs as $line) {
fputs($f, $line . "\n");
}
fclose($f);
} else {
echo "Extension not loaded!";
}
?>

and the contents of output.txt if I run it from the command line:

Code:

debugbreak
outputdebugstring
dbg_get_profiler_results
dbg_get_all_module_names
dbg_get_module_name
dbg_get_all_contexts
dbg_get_context_name
dbg_get_all_source_lines
dbg_get_source_context

Here is my debugging session:

Code:

$ dbg-cli
ListenerBase::ListenerBase
DBG php debugger, version 2.11.32, Copyright 2001, 2005, Dmitri Dmitrienko, www.nusphere.com
[DBG] parse_args(argc=1, argv=(null))
dbg>set mode off
[DBG] set mode->0 (off)dbg>set port 7870
dbg>set cgiexec /usr/bin/php
dbg>file /home/pellja/projects/tagnet/test.php
Reading symbols from /home/pellja/projects/tagnet/test.php...done.
dbg>run
ListenerBase::startsession
ThreadBase::ThreadBase
dbh_create_listen_socket(, 7870)
socket=3
open_dbg_session
open_cgi_session
olddir=/home/pellja/projects/tagnet
path=/usr/bin
open_cgi_session -> pid=6469 OK
ThreadBase::close()

Program exited.
Session start timeout has expired.
Program is not being run.
dbg>quit
ListenerBase::~ListenerBase
ListenerBase::stop
ListenerBase::stopJIT
stopping clients

As you can see, it is still failing. The output.txt file does not show up after the debugging session, so I know even though php was forked and started, it never executed my test script. Thanks for the good feedback. Let me know if there is more I can provide to help resolve this.

Cheers,

James

Posted: Sat Nov 05, 2005 2:39 pm

If you run Linux/x86, you may want to try dbg-cli binaries available on https://sourceforge.net/projects/dbg2 (see dbg-cli-2.11.32-glibc-2.2.tar.gz).

To investigate the problem with dbg-cli compiled by yourself, please try to fork a shell script which would dump content of environment variables and working directory into a file, for example:
file p.sh:
#!/bin/sh
set >./env.txt
pwd >>./env.txt

(don't forget to set exec permissions)
then run dbg-cli and set cgiexec /path/to/p.sh then file something.php then run then quit.
Dumped env.txt would contain the following variables:
REDIRECT_STATUS
REDIRECT_URL
SCRIPT_FILENAME
PATH_TRANSLATED
PATH_INFO
REQUEST_URI
REMOTE_ADDR
GATEWAY_INTERFACE
SERVER_PROTOCOL
REQUEST_METHOD

with correct values.

Posted: Mon Nov 07, 2005 1:10 am

Thanks again for your help. I am a gentoo user and have built both with the source code, and with the gentoo ebuild. Both behave exactly the same on my system. I would love to be able to continue using the ebuild as it makes upgrades automatic and easy. So, I would love to continue debugging. Here are the results from the test you suggested:

Code:

BASH=/bin/sh
BASH_ARGC=()
BASH_ARGV=()
BASH_LINENO=([0]="0")
BASH_SOURCE=([0]="/home/pellja/test/p.sh")
BASH_VERSINFO=([0]="3" [1]="00" [2]="16" [3]="1" [4]="release" [5]="i686-pc-l
inux-gnu")
BASH_VERSION='3.00.16(1)-release'
DIRSTACK=()
EUID=1000
GATEWAY_INTERFACE=CGI/1.1
GROUPS=()
HOSTNAME=pitcairn
HOSTTYPE=i686
HTTP_COOKIE=DBGSESSID=11314014094917350001@clienthost:10001
IFS='
'
MACHTYPE=i686-pc-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/kde/3.4/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linu
x-gnu/gcc-bin/3.3.6:/opt/blackdown-jdk-1.4.2.02/bin:/opt/blackdown-jdk-1.4.2.
02/jre/bin:/usr/qt/3/bin:/usr/kde/3.4/bin:/usr/NX/bin:/usr/games/bin:/opt/vmw
are/bin:/usr/share/karamba/bin
PATH_INFO=test.php
PATH_TRANSLATED=test.php
POSIXLY_CORRECT=y
PPID=3317
PS4='+ '
PWD=/home/pellja/test
REDIRECT_STATUS=200
REDIRECT_URL=test.php
REMOTE_ADDR=127.0.0.1
REQUEST_METHOD=GET
REQUEST_URI=test.php
SCRIPT_FILENAME=/home/pellja/test/p.sh
SERVER_ADDR=127.0.0.1
SERVER_NAME=localhost
SERVER_PORT=80
SERVER_PROTOCOL=HTTP/1.1
SERVER_SOFTWARE=DBG/2.1
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=1
TERM=dumb
UID=1000
_=/bin/sh
/home/pellja/test

For completeness I included the entire environment. It was created as you suggested, by forking off a new process through dbg-cli. I hope that gives you some more clues. It all looked reasonable to me. The debug info from dbg-cli all looked the same as before. Thanks again for your help.

Posted: Mon Nov 07, 2005 11:38 am

Just a bit more info... I compiled the binary I used above directly from the source tarball I got off of sourceforge. You recommended I try the binary from sourceforge as well... I have tried a session with that binary and get the same results. Still times out connecting to the forked php process.

Thanks for your help.

Cheers,

James

Posted: Mon Nov 07, 2005 6:18 pm

Quote:

HTTP_COOKIE=DBGSESSID=11314014094917350001@clienthost:10001

WHERE DID THIS ENV variable come from?
From your previous post
>dbh_create_listen_socket(, 7870)
it should contain port 7870, not 10001.

I see no reason why would PATH_INFO, REQUEST_URI and PATH_TRANSLATED refer to test.php while SCRIPT_FILENAME refers to p.sh.

there must be something wrong with your environment.

Posted: Tue Nov 08, 2005 12:36 pm

I noticed the SCRIPT_FILENAME issue and assumed it must be referring to cgiexec. Evidently that is not the case. The port mismatch is probably because I have 7870 in the config file, and I didn't specify a port for this test since p.sh wasn't going to connect back on it anyway... (Maybe I missunderstand something here...) Since dbg-cli didn't find anything on the default 7869, would it have tried 10001 automatically?

Anyway, it seems like PATH_INFO, REQUEST_URI, PATH_TRANSLATED, SCRIPT_FILENAME would all be set in dbg-cli and not be part of my default environment, so if they are wrong wouldn't it be a problem in dbg-cli? Any ideas on how I could correct the issues? I haven't had time yet, but I plan to dig into the code and see if something pops out at me there. Any ideas would be appreciated! Thanks for sticking with me on this.

Posted: Thu Jun 01, 2006 4:50 pm

I have this same problem. Has a solution been found yet? Thanks.

Posted: Sat Feb 24, 2007 5:48 pm

Same here with 2.15.1 from source.