PHP IDE :: NuSphere Forums :: View topic - >client ip address [NULL] lookup failed< solved

Posted: Mon Aug 30, 2004 8:38 am

Hi,

Just thought I'd share my solution...

On a fresh XP machine with sp2 I installed PHPEd 3.3.2 (3378), apache 2.0.50 and php 5.0.1 as a module... phpinfo.php worked like a charm.

I added this to my php.ini:

Code:

extension=php_dbg.dll-5.0.1
[debugger]
debugger.enabled=on
debugger.profiler_enabled=on
debugger.hosts_allow=localhost 127.0.0.1
debugger.hosts_deny=ALL
debugger.ports=7869, 10000/16

The error:
Whenever I pressed the single-step button in PHPEd, the following error was presented:

Quote:

DBG

Failed to run DBG session

reason:
client ip address [NULL] lookup failed
debugger request found in "query_string".
Not sure what it means? Visit http://www.nusphere.com/dbg/ for troubleshooting.

I imidiatly suspected the new enhanced and improved XP firewall, but that proved not to be the problem..

In an IE browser, I entered

Code:

http://localhost/_test.php?DBGSESSID=1@localhost:7869;d=1

which started the single-step debugging in PHPed.. Very weird..

Again from PHPEd I pressed the single-step, resulting in the same error as above.. Right-clicking, choosing Properties, revealed this URL:

Code:

http://localhost/_test.php?DBGSESSID=382306428853700007;d=1,p=0

see the difference? In the browser window opened by PHPEd, the "@localhost:7869" is omitted!

The solution:
In PHPEd I did:
Menu: Tools -> Settings -> Tab: Debugger
Here i deselected the "Auto Select Host" and entered "localhost" in the "Debugger host" field..

Now everything works Smile

Hope it'll help someone Smile

- Philip

Posted: Mon Aug 30, 2004 11:17 am

Hmm, could you please send me phpinfo() results at the email http://www.nusphere.com/contact_us/ ?
As far as I know dbg 2.16.12 handles empty hostnames in the requests without any problems...

TIA.

Posted: Tue Aug 31, 2004 3:19 am

Sure.. Its on its way Smile

Posted: Wed Sep 08, 2004 11:23 pm

I was having this same problem tonight and your post solved it for me.

Thanks!

Michael W.

Posted: Thu Sep 09, 2004 1:58 am

A debug session between Dmitri (NuSphere) and me, narrowed the problem down to the 'register_long_arrays = off' setting in php.ini-recommended.

Apparently PHPed (Or more correctly the remote debugger thingy) still requires the 'register_long_arrays' to be 'on', albeit the PHP team have depreciated this since version 4.1.0!

This is the quote from php.ini-recommended:

Quote:

; - register_long_arrays = Off [Performance]
; Disables registration of the older (and deprecated) long predefined array
; variables ($HTTP_*_VARS). Instead, use the superglobals that were
; introduced in PHP 4.1.0

The difference between php.ini-recommended and php.ini-dist is amongst other the 'register_long_arrays' setting. It is off in 'recommended' and on in 'dist'.

Two workarounds have been identified if you're experiencing this problem:
1) Set register_long_arrays = on
2) Use the method described in the bottom of the first post in this thread.

Posted: Mon Oct 11, 2004 6:31 pm

Quote:

Apparently PHPed (Or more correctly the remote debugger thingy) still requires the 'register_long_arrays' to be 'on', albeit the PHP team have depreciated this since version 4.1.0

Actually, according to the docs

Code:

register_long_arrays boolean
Tells PHP whether or not to register the deprecated long $HTTP_*_VARS type predefined variables. When On (default), long predefined PHP variables like $HTTP_GET_VARS will be defined. If you're not using them, it's recommended to turn them off, for performance reasons. Instead, use the superglobal arrays, like $_GET.

This directive became available in PHP 5.0.0.

See http://www.php.net/manual/en/ini.sect.data-handling.php#ini.register-long-arrays for full text.
As you can see this directive was introduced in 5.0.0. And it does not matter if long arrays ARE enabled or not.
Starting with Dbg 2.14 (and higher) it searches for DBGSESSID in
a) query_string (that is source for _GET and HTTP_GET_VARS)
b) $_GET
c) $HTTP_GET_VARS
d) $_POST
e) $HTTP_POST_VARS
f) $_COOKIE
g) $HTTP_COOKIE_VARS
h) $_REQUEST
i) cookie_data (which is the origin for _COOKIE and HTTP_COOKIE_VARS variables should they be enabled).

So I see no point for the claim... Smile