Hello,

I've got some problems with the dbg-php-5.3.dll (x86, VC6). I guess I have to reach out a bit to explain the situation:

I'm using XAMPP (http://www.apachefriends.org/de/xampp-windows.html) as development server on my Windows system (Windows XP Professional SP3). For quite some time this had been XAMPP 1.7.2 (with PHP 5.3.0), and I didn't notice any problems until some days ago. I had opened a local installation of the CMS Contenido (http://www.contenido.org/en/cms/index-d-230-4.html) that I had used in the past to look something up. When I tried to open the backend, I got an error message from Windows' Dr. Watson:


In English it should be something like this:


Well, I didn't really need this Contenido installation, so I looked up the needed information directly in the database and didn't investigate why this had happened.

The day before yesterday I updated XAMPP to version 1.7.3 (with PHP 5.3.1) using the update package. Afterwards everything seemed to work fine, and I even could use the two installations of MODx Revolution (http://svn.modxcms.com/docs/display/revolution/MODx+Revolution) (Beta 5 / SVN version of RC1) I'm working with without any problems.

Yesterday I updated PhpED to the latest build (5932) and added a project for each of the two MODx installations to my current Workspace, using the option "Web server (Apache or another) used for development is located on this machine".

Some hours later I tried to use the MODx installations, but the error message now applied to them, too - not a single page of backend or frontend could be displayed. On the other side, some other scripts - even complex ones like other CMS test installations - worked like a charm.

So I tried to find out what exactly happened:

• It wasn't browser-specific - it happened in Firefox as well as in Opera or Safari.
  
• I couldn't find any Windows Application that collided with the Apache service - I killed almost all non-vital processes, but the problem persisted.
  
• I downloaded the full XAMPP 1.7.3 distribution, compared it very accurately with my installation and corrected some items
  
• I deactivated Dr. Watson, but that just changed the error message:
  
  

  Quote:

  httpd.exe - Fehler in Anwendung Die Anweisung in "0x00ea39da" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden. Klicken Sie auf "OK", um das Programm zu beenden.

  
  which is in English
  
  

  Quote:

  httpd.exe - Application Error The instruction at "0x00ea39da" referenced memory at "0x00000000". The memory could not be "read". Click on OK to terminate the program.

When I commented out the line


in the php.ini, the problem had finally disappeared.

Well, the debugger is important for me, so I'll have to find out what happens exactly. At first, I thought that I had copied the wrong version of the dbg-php-5.3.dll to my extensions directory. I looked up the needed data via phpinfo():


Okay, so following the README in PhpED\debugger\server\Windows, I needed the file from the "x86" directory, and I copied it to the extensions directory again. It didn't change anything.

I don't have any clue where else to search for the cause for the problem. Could anybody give me a hint what to do? I'd really appreciate that... I do have a rather extensive Dr. Watson log file, but I don't know how to interpret it. If someone cares to take a look at it: I can be found at (http://debugger.enigmatic-web.de/drwtsn32.log) (1.35 MB).

Thank you very much in advance!

Cheers,
Jan

Hm, seems as if I'm the only one who experiences problems like this... I'd really like to use the debugger again, so if anyone had a hint for me, I'd be really grateful!

Cheers,
Jan

We are running into a very similair problem here.

Anyone been able to provide any help yet ?

In the meantime I have debugged MODx Revolution - the CMS where the problem occurred every single time - manually (echoing a test message and exiting the script). I found out that a custom session handler is defined, and in the moment the session is started, the Apache crashes (when the debugger DLL is loaded in the php.ini). To be exact, it crashes when a specific validator class is loaded using another class, but I couldn't find out what's different with this class. The loader class is used quite often, so I guess it's not the culprit.

There's a fallback option in case the custom session handler can't be initialized, so on my local server I just commented out the lines where the custom session handler is defined, and everything works just fine. But of course I'd rather like to have this bug erased from the debugger DLL...

Could you find out if your problem has anything to do with session management? Maybe we could circumscribe the problem a little if it has.

Cheers,
Jan