Hello all
I've experienced some strange problems when trying to debug some PHP scripts that use a COM object (developed internally, not a 3rd-party one). I use the latest PHP snapshot (5.1.3-dev) as ISAPI on IIS Web Server and the free DBG(2.11.32) compiled from sources to match the newest PHP distribution.
The server-side DBG extension is properly installed and works like a charm when not dealing with COM objects. As client, I use Maguma Studio Free Edition. Here is the phpinfo() result:

PHP Version 5.1.3-dev

System Windows NT WATCH 5.0 build 2195
Build Date Feb 20 2006 00:19:29
Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--with-gd=shared"
Server API ISAPI
Virtual Directory Support enabled
Configuration File (php.ini) Path C:\WINNT\php.ini
PHP API 20041225
PHP Extension 20050922
Zend Extension 220051025
Debug Build no
Thread Safety enabled
Zend Memory Manager enabled
IPv6 Support enabled
Registered PHP Streams php, file, http, ftp, compress.zlib
Registered Stream Socket Transports tcp, udp
Registered Stream Filters convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, zlib.*

Zend logo This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
with DBG v2.11.32, (C) 2000,2005, by Dmitri Dmitrienko
[...]
com_dotnet
COM support enabled
DCOM support enabled
.Net support enabled

Directive Local Value Master Value
com.allow_dcom 1 1
com.autoregister_casesensitive no value no value
com.autoregister_typelib 1 1
com.autoregister_verbose 1 1
com.code_page no value no value
com.typelib_file no value no value
[...]
dbg
DBG php debugger, version 2.11.32, Copyright 2001, 2005, Dmitri Dmitrienko, www.nusphere.com

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 On On
debugger.ignore_nops Off Off
debugger.JIT_enabled Off Off
debugger.JIT_host clienthost clienthost
debugger.JIT_level 3 3
debugger.JIT_port 7869 7869
debugger.profiler_enabled On On
debugger.session_nocache On On
debugger.timeout_seconds 300 300

The problem is that if I try to set a breakpoint for a line of code between the creation of the COM object( "$ComObject = new COM("blah.blah") ") and its destruction( "$ComObject = NULL;"), the debugger will be totally screwed up when reaching the breakpoint. All variables will be nil and trying to go further will raise an exception (i.e. in the browser a message like "PHP has encountered an Access Violation at 010EC574" will be displayed, of course, the hex adress is not fixed).
But, setting the breakpoint before the creation of COM object or after its destruction, there is no problem. All variables are displayed corectly and I can step without any problem until the COM object is created.
Of course, is worth mentioning that the PHP script (& COM object) works perfectly when not using the DBG debugger. Before, when using PHP 5.1.2 I had some problems with initializing COM objects but the broblem was solved with 5.1.3.

Any ideas ?
Thanks
Vilian

Okay... You're working with freeware debugger, freeware IDE and development snapshot of PHP...
I'm not really quite surprised this combination has crashed.

Did you try phped v4.0.1 & dbg 2.18.5? Module compiled for php 5.1.2 should work with 5.1.3-dev too.
If you want to stick with free version of debugger there are two ways to check the origin of the problem and I'd recommend you to try both:
1) compile DBG-Cli command line client utility. (try Cygwin under Windows or better run client on a Linux box). With this utility you can do mostly the same things as in IDE. If it does not crash php under the same conditions, there is high probability that the problem explicitly initiated by the IDE.
2) compile dbg module with Release_TSDbg target. The same for PHP. It will get you PHP and modules with debug info included so you'll be able attach debugger and see call stack at the crash point.


Finally, check your COM object intensively. Enable memory debugger when you compile all the sources including php, dbg and your COM object.

Thanks for your prompt response
Unfortunately, I don't have the commercial DBG (my managers don't know what PHP really is and I am a kind of a rebel, trying to convince them that using PHP is much better than the ASP they used before; so I don't expect having a comercial environment in the near future).

Regarding my problem, using PHP 5.1.2 or 5.1.3-dev didn't make any difference for debugging (I've got the same messages) but with 5.1.2. there was a bug (#35954 Fatal com_exception). Although, I have to admit that the php_dbg.dll was compiled for the 5.1.2 version and not for 5.1.3-dev (even so, does it make much of a difference ? )
Also, I've tried to use a sample COM object (i.e. all its methods were dummy, just returning some values) but I had the same result . This makes me think that not the COM object is the problem.

The first step will be try to recompile CORRECTLY the php_dbg.dll together with the php distribution because first time I wasn't able to compile PHP from sources on Windows but I grabbed an php5ts.lib from the XAMPP distribution and used it to compile only the php_dbg.dll. This might be a possible source of error.
If fails, I will try to use another IDE (free, like PHPEclipse ?) and in the end I will try to use the DBG-CLI command line utility as you suggested (on Linux or Windows).

Vilian

I to am having issues debugging PHP script with COM objects on XP. I wrote the COM component, and it works correctly, both when called by C++ or by PHP, except when in the PHP debug. I get a Windows error with the following.
CGI / FastCGI has encountered a problem and needs to close. I'm using PHP 5.1.4 and PhpEd 4.5.1. Any ideas?

I was able to debug a PHP script (that uses COM objects) but only when setting DBG breakpoints outside the lifetime of the COM object (that is, BEFORE creating the COM object or AFTER closing it. Between .... no way
I also tried with PHPEclipse but I get the same results. Also, I've tried a lot of COM objects: Microsoft Word, Excel, Adobe Illustrator and internally developed (DLL COM objects).

DBG module has no relation to COM and may not affect COM functionality. Could you submit code sample with Word or Excel that will replicate the problem you encountered?

Try this simple script and set a breakpoint after the "new COM( ...." line. You might have some problems with security settings regarding Word COM object. because the user as the script run is something like IUSR_??? with very limited access rights but you can solve it easily just assigning a different user.

<?php
// starting word
$word = new COM("Word.Application");
echo "Loaded Word, version {$word->Version}\n";

//bring it to front
$word->Visible = true;

//open an empty document
$word->Documents->Add();

//do some weird stuff
$word->Selection->TypeText("This is a test...");
$word->Documents[1]->SaveAs("c:\Useless test1.doc");

//closing word
//$word->Quit();

//free the object
$word = null;

?>

thanks for your sample.
It appears that COM extension creates php objects with NULL hashtable. While it's quite a nonsense and have never happened in php before (even 4.4.2 works pretty good), I fixed this at the dbg level. Below is a simple fix to be applied over 2.13.1 sources:

YEEEEEEEEEEEEEEESS!!!

I recompiled the php_dbg.dll library and PHP debugging works now like a CHARM .
Thank you very much Dmitri for your effort. Many PHP projects here involves COM objects and this is a big step forward for PHP acceptance.

I have never tried to work with COM and PHP before, but I've just tried the example... to be honest, that really feels perverted

Can't wait to make use of it , too bad it requires a Windows plattform... however, when you run applications on the desktop... *wink wink* @ddmitrie

The bug sounds like you should submit a bug report to fix it in PHP itself.

build 4523 will come with dbg-2.20.3 that fixes this problem.

ddmitrie, thanks for build 4523. It fixed the problem!