Hi,

I can confirm this problem.

I have this problem few months, but not with drupal, but with Zend Framework Application, the environment is the same, latest Eclipse/PDT latest stable XDebug and PHP 5.3.1-5.3.3.

This issue kill my Apache server ( latest stable version) very often 3 times from 10 debug sessions.

Faulting application name: httpd.exe, version: 2.2.17.0, time stamp: 0x4cbbe9e8
Faulting module name: php_xdebug-2.1.0-5.3-vc6.dll, version: 2.1.0.5, time stamp: 0x4c29c7d8
Exception code: 0xc0000005
Fault offset: 0x0000bf44
Faulting process id: 0x938
Faulting application start time: 0x01cbb9419ec841dc
Faulting application path: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\bin\httpd.exe
Faulting module path: C:\Program Files (x86)\PHP\ext\php_xdebug-2.1.0-5.3-vc6.dll
Report Id: 88720566-2535-11e0-9e20-005056c00008

Hi,
Do you know if this can be solved somehow? As you know very well, it's very time consuming when you have to close Xampp and Eclipse, disable some drupal modules, restart Xampp and Eclipse and Apache, try again by starting debugger, enable drupal modules (if you are lucky to get that point) etc... Br, Markku R

Having exactly the same issue debugging Wordpress with Eclipse on Windows. Virtually unusable. Have tried this on XP and Vista with the same results.

I would need a proper backtrace (see http://bugs.php.net/bugs-generating-backtrace-win32.php), and if you can, a simple script and a remote_log (see http://xdebug.org/support.php#remote). I've uploaded a debug pack for 2.1.0-5.3-vc6.dll as attachment to this report. (For fun, do try 2.1.1 though please).

Unfortunately, 2.1.1 does not solve the issue. As it turns out, it is crashing when the variable view panel is open. As long as that is closed, it seems to work. Inspect works fine. Also, syntax highlighting is still not working. Had to disable it. Thought I read another post where syntax highlighting was fixed. Anyway, if you keep the expressions and variables panels closed and disable syntax highlighting it works pretty well.

If I can figure out how to send you a backtrace, I will. Not sure what is meant by, "I've uploaded a debug pack for 2.1.0-5.3-vc6.dll". Can't seem to find the file.

Thanks

Hello,

A user of my application is having similar problems, he managed to get backtrackes of it, I attached them in XdebugReports.zip.
If you need more information, let me know.
Thanks.

I have had this issue debugging Joomla in Windows Vista 64-bit with Xdebug and Eclipse. As a work-around, I find it works if I keep the Variables view closed and just use the Expressions view. However, this is a major limitation. It would be very helpful to get this issue resolved.

Don't know if this help, I have same kind of issue, but it relate to array depth xdebug handle in Variables view. And you can change it. Widnow > Preferences > PHP > Debug > Installed Debug > Xdebug > Configure enlarge the "Max array depth" solved my issue.

Hi,

I can partially confirm efeng's workaround. I enlarged the "Max array depth" from to 50 but that alone didn't do the job. What I had to do: Ensure that the variables view is NOT selected (it can be there but in background). Step to a breakpoint and do an inspect of some variable once -> The variables view now displays all variables correctly.

Hi Everybody,

I'm new to Eclipse and XDebug, so if i say something stupid - please don't flame me. I'm using Eclipse PDT as my IDE, and since ZendDebugger failed miserably, i decided to try XDebug. Plus everybody (who i know that develops in PHP) said that it's superior debugger.

I'm trying to setup Eclipse/XDebug for Joomla extension development. I've used another IDE with no debugger, but as web app grows it's a huge setback to work without a debugger, it's not the most efficient way to work.

As this issue, and other issues related to it point out, my problem is Eclipse throwing: "unexpected termination of script, debugging ended" error when i run the debugger, if "Variables" tab is visible. My problem is not related to Drupal, (as i said above I'm working with Joomla) but I'm sure the source of this issue is the same. And though other subjects might be describing my problem more accurately, i didn't want to write to to threads/issues which were marked as "duplicate" of this by admins.

I actually tried to do this setup of Eclipse + XDebug on older machine which had Windows XP and Apache/PHP/MySQL were installed and configured separately. That setup did not have this problem, which makes me think if maybe the issue is also XAMPP related (i'm using XAMPP for a first time now). Is anybody else who has this problem using Apache/PHP without XAMPP package? Just an idea...

I did as zenobios advised. I made sure that "Variables" tab is not selected prior to debugging. Once i hit first breakpoint, i inspect the variable and once it shows me the variable contents, i can safely view the "Variables" tag. More than that, on next session it works even if "Variables" tab has been selected initially. On 3rd try however same thing happens: "unexpected termination of script, debugging ended".

It's a nice workaround, which at least will let me work little bit if I'm careful. So THANK YOU zenobios = kudos+1 :) thumbs up

Here is a link to file with my XDebug remote log contents:
http://www.starlingwebdevelopment.com/4xdebug_developers/xdebug_remote_15Aug2011.log

I cant use MS Debug Diagnostics Tool as instructed in the link above, since I'm running Windows 7. Debug Diagnostics Tool only shows very small part, saying "Analysis Only". So i cant create rules etc... Though I've downloaded PHP Debug .pdt file set into my PHP installation. Not sure how to use them without full Debug Diagnostics Tool though....

Here are my XDebug settings in PHP:

[XDebug]
zend_extension = D:\xampp\php\ext\php_xdebug-2.1.2-5.3-vc6.dll
xdebug.default_enable = "On"
xdebug.profiler_output_dir = "D:\xampp\tmp"
xdebug.remote_enable = true
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "localhost"
xdebug.remote_log = "D:\xampp\php\log\xdebug_log\xdebug_remote.log"
xdebug.remote_port = 10000
xdebug.show_local_vars = 1
xdebug.trace_output_dir = "D:\xampp\tmp"

(I've tried also setting my XDebug max array options higher, but yielded same result. Are these correct options of which efeng was speaking? Or i misunderstood totally?)
xdebug.var_display_max_depth = 100
xdebug.var_display_max_data = 2048
xdebug.var_display_max_children = 512

(I don't know if this is going to help any, but just in case...)
And here is Windows EVENT VIEWER error message that is generated during the crash:

Faulting application name: httpd.exe, version: 2.2.17.0, time stamp: 0x4cbbe9e8
Faulting module name: php_xdebug-2.1.2-5.3-vc6.dll, version: 2.1.2.1, time stamp: 0x4e317b06
Exception code: 0xc0000005
Fault offset: 0x0000bee9
Faulting process id: 0x508
Faulting application start time: 0x01cc5b1d0a3c1891
Faulting application path: D:\xampp\apache\bin\httpd.exe
Faulting module path: D:\xampp\php\ext\php_xdebug-2.1.2-5.3-vc6.dll
Report Id: 4e063037-c710-11e0-a423-005056c00008

If i can provide anything else, please let me know. It's very important for me to get this working (as I'm sure for everybody else), and I'll do anything that i can to help find the source of this problem.

Thank you everybody for reading this long message.

its this going to be fixed?
this bug makes the debugger almost unusable. sometimes i can debug and watch variables, and sometimes the debugger crashes almost instantaneously.
it seems that the bug has something to do with the size of the call stack. but im not sure

I was having this problem (as reported on 2011-06-10), but after upgrading to XAMPP 1.7.7 (PHP 5.3.8 and XDEBUG 2.1.1) XDebug is mostly stable and I can use the Variables view. I found that I need to have "Show super globals in variable view" turned off. But with that, I can use the Variables view OK. The only time I crash now is if I forget to disable or delete certain expressions in the expressions view and stop at a place where an expression causes an error. Hope that helps someone.

Could you please try Xdebug 2.2.3 which has just been released? I am suspecting that release might fix this issue.

aparently with the new version its solved.
Thanks!

Apparently fixed in 2.2.3!