I configured a new staging server a few days ago that matches those specifications and was planning on adding the debugger to it today, so I'll let you know how that goes.

I've had exactly the same response in the past from a well known NuSphere competitor, for a license that was only 1-week expired.

I am probably getting the same error.

Apr 28 15:00:51 stage kernel: php-fpm[29337]: segfault at 60600000001 ip 00007fd51efcd270 sp 00007ffc86605580 error 6 in dbg-php-7.0.so[7fd51efb5000+2c000]

With this new server I can switch individual sites to different PHP versions and PHP 5.4 / 5.6 are both working fine, just 7.0 crashes.

I've reported it.

I had similar experience few year ago, when I've tried to submit the obvious issue with indent guides. It was fixed only in the 17 version.

Unfortunately, there are a lot of other errors and bugs. For example, when I'm debugging a script and moving a cursor on some variable, the popup with it's value appears in quite different place:



Recently I've arrived at a decision to switch to the other IDE after a 4 years of working with PHPed. The main reason - is the lack of many important features.

For example, there is no option to fast switch the listening to the remote debugger. It's very useful for debugging the AJAX queries. On my current IDE I just turn on the listening, make an AJAX request and catch all necessary information on the breakpoints. After the debugging I turn off the listening in IDE to prevent the unnecessary debug sessions. All this things I can make without configuring the URL paths or even page reload in browser.

Another important feature is the inline variable representation during the debug session. In current IDE I can see all variable values without finding them in large list or pointing them using mouse. It may sounds strange, but it really saves my time and make the debug easier.

Besides the debug-related features there are a lot others, which are not present in current PHPed version. For example, there is no feature to specify my own code style and automatically format the code, when I'm working with another's project or pasting it in the editor. It's a fundamental IDE feature, which is still missing in PHPed.

Unfortunately, the PHPed is one of the few IDE without Emmet support. This feature is also essential for a modern IDE and it's very strange that it's still missing in PHPed. The another feature that I miss in PHPed was the file names auto-completion. Sometimes it take a lot of time to find the proper image, find out its size and paste in in the CSS.

The framework support is one of the PHPed's strong points, but where is the support of WordPress? The 35-50% of all sites across the Internet are built using this CMS. When I'm talking about support, I mean auto-completion for add_filter/add_action and a lot other frequently used functions.

Now I'm using the PHPed only when I need to edit, download or upload few files on the remote host.

You can click the edge of that popup and drag it to be closer to the variable

Occasionally I've dragged it too far away and then you have to be very quick with the mouse to be able to drag it back again!

Code completion in WordPress works fine for me without any framework support required. Maybe try refreshing Code Explorer or make sure you haven't excluded any directories from the project. A lot of the WP functions are in the global namespace anyway (ugly framework!), so should always be available to code completion.

If you are using the same IDE that I think you are using, the inline variable display is sometimes useful, sometimes a pain and sometimes unusable. Also I found it doesn't work after making a code edit during a debug session and I often make code edits when debugging.

For sure PhpED is missing lots of features that you expect from an IDE these days. Getting back on topic with PHP 7, I will still continue to use PhpED for any reasonably involved debugging, but I can no longer use it for all of my coding.

Yes, it is possible to drag that popup window with values, but it's useless in most cases. Actually, I don't need that window. I just want to know the variable value with a minimum of efforts. If I need to search the popup with value on the whole screen, It's confusing.

Talking about the WordPress support I've meant something else. The completion for function or variable names really works. Yes, there is some space for improvements, but it is usable in current implementation. I'm talking about the auto-completion for most used function parameters. For example, when I'm trying to add a new filter using add_filter or add_action functions, I'm expecting that the IDE will propose me a list of built-in event names. In current PHPed version I need to search the event name in the whole project to be sure, that I've typed the event name correctly. The best way to debug is to write the code which doesn't require further debugging.

Sorry for the off-top.

On the other hand, just because they say that to you doesn't mean they are not investigating the problem.

I have a dialog going with Dmitri at this very moment looking at the problem.

Jay might be referring to yours being the only report through the frontend support system. My report was through the beta testing system.

This probably should be a different thread by now

In my case I was able to trace the problem to my using an auto_prepend script which was causing DebugBreak() to fail. I was using DebugBreak() to test with because I didn't have a project setup for anything on the new server. I created a project and debugged through the server using breakpoints, which appears to work fine.

Now working with Dmitri to try and find out why this auto_prepend script and DebugBreak() cause the PHP exception. Might even be a PHP 7 bug.

The cause of PHP crashing for me appears to be having a global variable being assigned to an object in an auto_prepend_file script, together with using DebugBreak() with an argument. It is possibly a very unusual scenario and could be a PHP 7 bug.

If I had configured a project for debugging and used that for testing, it is unlikely I would have had a problem.

In other respects at the moment PHP 7 debugging appears to be working fine.

segfaults in php7 are expected.
Look at their changelog for 7.0.7 http://php.net/ChangeLog-7.php#7.0.7
Bug #72162 -- use after free
Bug #72101 -- crash on complex code
etc
All these bugs are not fixed in 7.0.6 and btw there are many other fatal bugs in 7.0.7 to be fixed.

RE Neil, he got rid of crashes after server restart.
Perhaps, he "re-loaded" apache to pick new php configuration. This is a known way to get crashes.

I'm in the process of replacing my existing web servers with newer ones. These new ones all have:

* CentOS 7.2.1511
* Apache 2.4.6
* At the time of the issue using PHP 7.0.5 but now 7.0.6
* So that means it is now PHP 7.0.6 (fpm-fcgi) built: May 4 2016 18:32:28
* Zend OPcache 7.0.6 (even when using PHP 7.0.5, but turning OPcache off did not change issue)
* nginx 1.9.14
* Plesk 12.5 latest build, which is also automatically updating PHP, nginx and Apache to what Plesk consider to be the latest stable builds (normally a few weeks behind the latest version release)

These are Plesk maintained builds of PHP from the Plesk repository; it was actually why I chose Plesk for this because they are now managing the PHP builds. The core CentOS PHP is no longer used for web services (it can be, but I don't). From the Plesk admin you can switch sites between any stable release of PHP between 5.2 and 7.0

The server I had the debug problems on was the new staging server, which is identical to all of the others. It is possible it had not been restarted since it was first setup.

Prior to the restart I could 100% reproduce the problem using specific scripts where one of those scripts was an auto-prepend. Including that script directly so it was no longer an auto-prepend worked fine. My testing gave me good reason to believe PHP 7 was hiding a static class from the prepend script. I think the debugger trying to access that class (which it should be able to) and that was causing the crash.

I could also work around the problem by using a couple of specific actions and the problem only occurred when using DebugBreak(). It did not occur when I used breakpoints.

Since the restart and whilst it was still on PHP 7.0.5, I could no longer reproduce the PHP crashes.

It doesn't sound like the same crash probc2 was getting.

If there is a problem with stability (either in php or in debugger), it makes sense to try to reproduce the problem using php command line. If it is reproduced (even in a few runs out of many), you can run the same under valgrind's memcheck tool. Very good chances it will find memory errors, and what's more important it may show callstack and location where the problem is. If it is in php, you can submit them bug report. If it's debugger, you're welcome to provide us with the results.
You may want to run valgrind like below
valgrind --tool=memcheck --main-stacksize=50000000 --verbose --num-callers=24 --gen-suppressions=all --log-file=programname.vg-%p.log php /path/to/your/script yourscriptarg1 yourscriptarg2 ...