Prev: PHP 4.4.9, Windows: php_openssl.dll is loaded, buthttps wrapper not found.
Next: Echo is buffered despite ob_implicit_flush(1)! Help please
From: "Herb Munson" on 13 Feb 2009 01:02 Well, I'm now set up with CGI on my XP - IIS 5.1 - PHP 5.2.6 system. And its much more fun now, it doesn't seem to be kicking off all those Access Violations, as isapi did. Many thanks for that. But now where xdebug worked (on those rare occasions without access violations) - nada. NetBeans tries to load xdebug, and tries and tries, and nothing good happens (it doesn't connect). I'm using php_xdebug-2.0.4-5.2.8-nts.dll, corresponding to the download link "5.2 VC6 Non-thread-safe". Looks right to me, but what do I know. (Yup, the ini file points to this replacement for the ts version I used before, and the 4 xdebug parameters are set.) If the dll isn't the problem, there doesn't seem to be much more that could be wrong. So simple, yet I've screwed it up. Any suggestions? It would REALLY be nice to have a debugger. Banging my head against the wall is starting to hurt quite a bit.
From: Elizabeth M Smith on 13 Feb 2009 10:11 Herb Munson wrote: > Well, I'm now set up with CGI on my XP - IIS 5.1 - PHP 5.2.6 system. And > its much more fun now, it doesn't seem to be kicking off all those Access > Violations, as isapi did. Many thanks for that. > > > > But now where xdebug worked (on those rare occasions without access > violations) - nada. NetBeans tries to load xdebug, and tries and tries, and > nothing good happens (it doesn't connect). > > > > I'm using php_xdebug-2.0.4-5.2.8-nts.dll, corresponding to the download link > "5.2 VC6 Non-thread-safe". Looks right to me, but what do I know. (Yup, the > ini file points to this replacement for the ts version I used before, and > the 4 xdebug parameters are set.) If the dll isn't the problem, there > doesn't seem to be much more that could be wrong. So simple, yet I've > screwed it up. > > > > Any suggestions? It would REALLY be nice to have a debugger. Banging my > head against the wall is starting to hurt quite a bit. > > As the Xdebug docs mention: If you're loading it as a zend module remember to use zend_extension=/path/to/xdebug NOT zend_extension_ts=/path/to/xdebug or it'll never load (since you're using the non-thread safe version) Thanks, Elizabeth
From: "Herb Munson" on 13 Feb 2009 15:59 To try and understand why netBeans 6.5 (Build 200811100001) spins its wheels trying to connect to xdebug, I ran sysinternals process monitor and included only events wherein the "process name" included "php". Rationale: I assume that if I run a project from netBeans, or use Mozilla to open http://localhost/phpinfo.php?XDEBUG_SESSION_START=mysession, then php will try to load xdebug, and that event will show up in procmon. (btw, iwbn if procmon would make it easier to filter out anything outside the time of the first and last events in the current display.) The expected xdebug events do not happen. 1. Experiment 1. Initially, procmon shows no events. Start the netBeans debugger. Procmon is populated with 2781 events for which the process name contains php. "find" finds 2 instances of the string "xdebug" in those events, both in the "detail" field of a directory query. There are 40 instances of "php5ts.dll", including a successful "load image"! I thought CGI was non-ts; why is php-cgi.exe loading this? 2. Experiment 2. Procmon again cleared of events. Mozilla opens /localhost/phpinfo.php?xdebug_session_start=yada Populated with 5685 events Finds 2 instance of "xdebug", both in "detail" of directory query. So it looks to me as though php is not <trying> to load "xdebug". Why not? Is my approach nuts? (at this point.I am!) Suggestions? Is there some other way to figure out what's going on? Herb BTW, my php.ini settings: zend_extension = C:\php\ext\php_xdebug-2.0.4-5.2.8-nts.dll ;;;;;;;;;;;;;;;;;;; ; Module Settings ; ;;;;;;;;;;;;;;;;;;; ;[Xdebug] xdebug.remote_enable = on xdebug.remote_handler = dbgp xdebug.remote_host=localhost xdebug.remote_port = 9000
From: "Herb Munson" on 13 Feb 2009 16:45 Right, I'm using zend_extension = C:\php\ext\php_xdebug-2.0.4-5.2.8-nts.dll I just posted the results of some experiments with procmon - along with the pertinent entries in my ini file. Incidentally, Procmon shows that php-cgi.exe seems to load php5ts.dll; what's up with that?? From procmon: Proess PID Operation Path Result php-cgi.exe 5864 Load Image C:\php\php5ts.dll SUCCESS Hmmm. Does php-cgi.exe know to look for the non-ts extension? Could you not have both keyword assignments in the ini, and let php take the one it needs? Anyway, thank you for the response, and I'll keep bashing away at this... Herb -----Original Message----- From: Elizabeth M Smith [mailto:auroraeosrose(a)gmail.com] Sent: Friday, February 13, 2009 7:12 AM To: php-windows(a)lists.php.net Subject: Re: XDEBUG with 5.2.6, IIS 5.1, CGI Herb Munson wrote: > Well, I'm now set up with CGI on my XP - IIS 5.1 - PHP 5.2.6 system. And > its much more fun now, it doesn't seem to be kicking off all those Access > Violations, as isapi did. Many thanks for that. > > > > But now where xdebug worked (on those rare occasions without access > violations) - nada. NetBeans tries to load xdebug, and tries and tries, and > nothing good happens (it doesn't connect). > > > > I'm using php_xdebug-2.0.4-5.2.8-nts.dll, corresponding to the download link > "5.2 VC6 Non-thread-safe". Looks right to me, but what do I know. (Yup, the > ini file points to this replacement for the ts version I used before, and > the 4 xdebug parameters are set.) If the dll isn't the problem, there > doesn't seem to be much more that could be wrong. So simple, yet I've > screwed it up. > > > > Any suggestions? It would REALLY be nice to have a debugger. Banging my > head against the wall is starting to hurt quite a bit. > > As the Xdebug docs mention: If you're loading it as a zend module remember to use zend_extension=/path/to/xdebug NOT zend_extension_ts=/path/to/xdebug or it'll never load (since you're using the non-thread safe version) Thanks, Elizabeth
From: Elizabeth M Smith on 14 Feb 2009 13:54
Herb Munson wrote: > Right, I'm using > > zend_extension = C:\php\ext\php_xdebug-2.0.4-5.2.8-nts.dll > > I just posted the results of some experiments with procmon - along with the > pertinent entries in my ini file. Incidentally, Procmon shows that > php-cgi.exe seems to load php5ts.dll; what's up with that?? From procmon: > > Proess PID Operation Path Result > php-cgi.exe 5864 Load Image C:\php\php5ts.dll > SUCCESS > > > Hmmm. Does php-cgi.exe know to look for the non-ts extension? Could you > not have both keyword assignments in the ini, and let php take the one it > needs? > > Anyway, thank you for the response, and I'll keep bashing away at this... > > Herb > If it's trying to load php5ts.dll I suspect that your IDE has it's own install of PHP somewhere (fun fun) Do a search for php-cgi.exe on your system and see how many hits you are getting. You can have a LOT of different php's installed simultaneously which can be both helpful and confusing (heh, I think I have 16 on this test box here - ugh) Really I haven't had any luck getting debugging working on windows with PHP with any IDE but Komodo ;) So - good luck! Thanks, Elizabeth |