Configuration details:
PhpED 3.3.3 on Windows XP
Debugger is on port 7869 tunneled through SSH
Web server is running Linux 2.2.14 with Apache 1.3.14
PHP version on the web server is 4.1.2 (verified using phpinfo())
DBG version is 2.16.15 (dbg.so-4.1.2) (verified using phpinfo())

I'm trying to use PhpED to debug a web service written in PHP. Because the PHP is called directly by an application, it seems that the only choice I have for adding a breakpoint is to add DebugBreak() to the code. I'm fine with that. However, I can't seem to get it to work.

For troubleshooting purposes, I tried running the page directly from the IDE and that works fine (using either the Run command in the Run menu, or Open URL in the Tools menu -- both work fine). The debugger starts and I can successfully step through the code as long as the PHP code does NOT contain DebugBreak().

As soon as I add DebugBreak(), the page refuses to execute at all. The request doesn't even show up in the access_log on the server. However, the error_log on the server shows:

/usr/local/etc/httpd/bin/httpd: error in loading shared libraries: /home/php/php-4.1.2/ext/dbg/dbg.so-4.1.2: undefined symbol: request_init

If I remove DebugBreak(), then I can execute from the IDE again. Of course, without DebugBreak(), I can't debug when the code is called by the application, so I'm stuck. Any ideas?

Please check is libwrap is installed on your system.
On many systems this library comes with tcp_wrappers package.

[root@dev /root]# rpm --query libwrap
package libwrap is not installed

[root@dev /root]# rpm --query tcp_wrappers
tcp_wrappers-7.6-10

It seems odd that I'm able to establish a debug session if the client initiates the session (via the PhpED IDE), but not when the server attempts to initiate the sesssion (via DebugBreak).

Maybe some problem with your tunneled setup - upon hitting debugBreak(), how does the dbg extension know it has to connect to the "local" end of the ssh tunnel?

> Maybe some problem with your tunneled setup

Possibly, but it works when the IDE initiates the debug session. In addition, if I type "telnet localhost 7869" on the server, it can sucessfully connect back to the client.

Finally, I discovered that if I change my Win32 application to include the special "DBGSESSID=0@localhost:7869;d=1" variables as part of the request, then the PhpEd debugger starts successfully. This is what I'm currently doing in order to get my work done, but I'd still like to find a solution to the DebugBreak problem so I don't need to modify my Win32 application in order to debug the PHP code on the server.

It's been less than 30 days since I purchased, so I'll probably contact tech suppport directly.

That's what I expected - when starting the session from the IDE, it will append the necessary DBGSESSID parameter to connect to the localhost ssh tunnel end.

As there's no DBGSESSID parameter when calling debugBreak(), the debugger will try to connect to the default 'clienthost' address.

I asked ddmitrie to change debugBreak() to accept the DBGSESSID string as a parameter. Maybe that will be in the upcoming 4.0 release?

> As there's no DBGSESSID parameter when calling debugBreak(), the
> debugger will try to connect to the default 'clienthost' address.

Is there a configuration setting on server for this? If so, where is it located and what should I set it to (localhost?)?

> I asked ddmitrie to change debugBreak() to accept the DBGSESSID
> string as a parameter.

Are you saying that DebugBreak() doesn't work for you either? I've seen other posts here that seem to indicate DebugBreak() works for them, but maybe they aren't tunneling via SSH?

There's no such server setting.

debugBreak() works fine unless you have to point it to the local ssh tunnel end.

> There's no such server setting.

If that's the case, then I'd like add a second vote for changing DebugBreak() to accept a parameter for DBGSESSID.

you may want to specify
[debugger]
debugger.JIT_host=localhost
in this case

This setting is used when DBGSESSID is not specified.
Alternatively you may want to use
DBGSESSID=1@localhost:7869;d=1;s=1000

(s=1000 means do not start debug session in next 1000 requests and the counter works through the cookie) so effectively it will not start debug session immediately, but dbg will know what host to connect to to start debug session when it reaches DebugBreak().