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

Hi,

I just bought phped for it's debugging ability and this certainly sounds like a similar problem to what I'm having. I'm actually using WAMP not XAMPP, and I'm on a VISTA 64 machine.

Like I think you were saying, my Apache server is crashing on normal browsing when the dbg dll is called in the php.ini. I've tried a couple of variations so far and while the pages that crash change, I haven't gotten any satisfaction. But when it crashes there is a button for more details which says specifically that the debugger module is where the fault is.

Problem Event Name: APPCRASH
Application Name: httpd.exe
Application Version: 2.2.11.0
Application Timestamp: 493f5d44
Fault Module Name: dbg-php-5.2.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4c763a6d
Exception Code: c0000005
Exception Offset: 000027ef
OS Version: 6.0.6002.2.2.0.768.3
Locale ID: 1033
Additional Information 1: fd00
Additional Information 2: ea6f5fe8924aaa756324d57f87834160
Additional Information 3: fd00
Additional Information 4: ea6f5fe8924aaa756324d57f87834160


Did you (or anyone) ever get a fix? Did support help you out at all, or did you contact them?

Also, I was curious if you (or anyone) happened to look at the details of the crash and if they are similar to the ones I posted.

The project I am browsing requires use of Ioncube decoder as well, which I wonder if it is causing problems.

Thanks in advance

I didn't contact the support team; the problem with MODx Revolution was fixed by the MODx team (see http:/ /modxcms.com/forums/index.php/topic,47137.msg282518.html#msg282518). I still believe that there's a bug in the debugger (sounds funny, eh? ), but since everything's working fine at the moment, I don't pursue it right now.

I had a similar problem with PhD, but I didn't test this for a while.


The crashes I experienced were absolutely reproducable, but you said the pages that crash change, so I'm not absolutely sure if this is the same problem.

Cheers,
Jan

Hm, I just tested it, but PhD didn't cause any problems, too.

Cheers,
Jan

Wow, thanks for the quick reply and for checking. I'll read through that thread to see if maybe I see some other similarities. But looking at modx requirements I can see it doesn't require ion-cube. That seems to be a sticking point in m y situation. Even when one of the pages does not crash the server, there are some specific license related class functions that are encoded with ion-cube that are never performed.

The pages that crash only change when I change the php version. I can install multiple versions of php and Apache and change them on the fly, though they have to be configured. But the pages that cause crashing stay consistent within each version combination so far. So I can reproduce them consistently. They just change per my server version combination. I see myself installing many versions of php and Apache in the near future. Yayyyyy.

But it does rather seem to me that it is a bug in debugger as it is the faulting module.


Thanks again!

There's a rather unpleasant quarrel between me and another user in it. I hope you'll nevertheless find the needed information.

Cheers,
Jan