We have upgraded to version 13 (latest build 64 bit build 13041) and now having overcome the debugger properties bug (due to fix in latest release) we have another issue preventing debugging.

The debugger is started and runs through a few steps (manually step into or over) but then exits out of debugging mode for no apparent reason and what would appear to be totally random as it can occur at any point in any file. We usually only get through 4 or 5 steps when a modal error box appears stating "Internal debugger error: session prematurely finished".

This was not an issue when debugging with version 11 of PHPEd which had no issues with the debugger (that we experienced).

Please advise how to resolve this issue as we can not debug without it.

I share your pain. I get these virtually every day. Generally what helps (not resolves the issue):
- clear all breakpoints
- remove all watches
- restart IDE

If that doesn't help, then:
- delete .idx and .ppx files of the project
- start phped
- leave it crunching
- restart phped

And then usually I'm able to debug the point in code which previously caused "Internal debugger error". Although it will always reappear somewhere else at some other point.

Thanks, let me try what you say and see if it at least alleviates the issue, if not removes it - it is very frustrating because we had absolutely no issues debugging with version 11. Hopefully only a temporary bug.

If you have not already reported your debugger issues to Nusphere, then you really should.

I've been testing Beta versions for a few months now, and have not had one single debugger error like you've described.

Please don't assume that others are aware of these issues. Nusphere might of course already have had reports and be well aware, but would possibly find your assistance very helpful.

On the other hand, you might be the only two, so if you don't report it you might be waiting a while for a fix

Debugger versions have been updated a bit recently; have you confirmed you are running the correct versions of DBG for your version of PhpED?

Also consider checking the logs on your server for any useful errors.

Your list is by far incomplete. You'd try the most powerful steps: tambourine dance and at least 1-2 animals sacrificed to the Gods.
Seriously guys, do you think deleting those files can ever help debugger work?



nope yet

I actually did and it was a complete disaster. Each time I got first non-robot reply after at least a week, sometimes even 2 weeks. First time all i got was something like "try it with techplatform". Which I refused because the project relies on PHP 5.5 which TP still does not support. Second time when I got fed up again and filled another bug report, we got a bit further - to the fact that I am using ApacheLounge server (obviously unsupported by PhpEd, though recommended by PHP) and that i should use "proper" version in Techplatform. This time I decided to modify the code to make it compatible with PHP 5.4, did so (got same error on my server) and installed TP which failed to work. It crashed because it insisted on using PHP libraries from PATH and not it's own directory and the support guy insisted on me removing all of my current installation of PHP. I would even try that, but with the replies having the frequency of 3-5 working days and no solution in sight... - I just can't keep my development environment crippled for months... Third time I tried to report it I got no answer at all, probably because the new v13 came out and I was supposed to upgrade (which I did and it did not help).



Yes, because the issue happens only on one project out of the ten I'm working on. Never happened on the others.



Overall the communication with support is truly horrible, because the they never (or very rarely) quote the original description. Sometimes even not the email answers. And they never let you know whether something is happening (i.e. the ticket is waiting in queue, someone is looking at it, it has been ignored, resolved or whatever). It's just pure arrogant, because they automatically assume that when I filled a bug report, I do remember the steps to reproduce for weeks and obviously I have nothing else to do, but wait for their reply - so in their reply they do not have to provide any context. This combined with the fact, that the response times is at best days (sometimes weeks and never hours) means that I want to continue working I need to find a workaround by myself.



Yep, I update the dbg DLL every time i update PhpEd, because it sometimes is not mentioned in changelog, that the module changed, even if a new version cam out.



Unfortunally, there are no errors at all on the server.

I probably would not have posted my earlier reply if you had mentioned 1 project in 10 consistently causes this issue as that somewhat changes the analysis

Whilst I personally do see the value of a forum based system for the analysis of some issues, I also understand that NuSphere find it hard to use the forum for their own support communication. I do find their support emails difficult to follow due to lack of a trail. I'm sure there are forum and support applications available that could provide better results.

With 1 in 10 projects, does that mean you have 40 projects and 4 fail consistently fail, or is it really 10 projects you have in total and just 1 fails? That makes a big difference to scope and also helps identify a common factor between those failing projects.

I'm guessing NuSphere suggested TechPlatform just so they could try and understand if the problem happens with a 'known' PHP installation that they are familiar with. It sounds like TP did not resolve anything; did you load any of your own extensions or just use the ones in-the-box? Do your extensions load before and/or after DBG?

I use TP myself on Windows and have done since I first used PhpED. Currently on one server I have two separate TP's one with PHP 5.2 and the other with 5.4; I switch between them by using ports 80 and 86 respectively. I also have various Linux (all CentOS) with various Apache/PHP versions between 5.2 and 5.5. The majority of my debugging is with Windows Apache (not IIS).

I've had the occasional debugger issue, mostly resolved except for one which is actually a problem with PHP 5.2, but have never seen an internal debugger error.

Are you running the debugger on Windows or Linux? You could try debugging on an alternative OS to see if that changes anything.

From what you've said, there does appear to be something 'different' about your project.

Is there anything you can share about your project that might show a pattern and allow others to assist?
* PHP framework
* specific areas/statements where the problem seems to occur
* activities at the time of failure; are you profiling, huge number of watches, previously entered immediate statements, etc.
* which version of PhpED did this problem start with, or has it never worked
* using any encoded (protected) files
* unusual activities by your code, such as large memory usage, big arrays, etc.

Yes, but I'm not the author of this thread, his problem may indeed be another one.



It is only 1 project (unfortunately the one most active). I have about 10 other projects I regularly work on, and none of them have the issue.



Apart from the debugger, I use just the extensions shipped with PHP. Both the PHP and Apache configuration is mostly left to default.



I do all debugging on windows. I don't use Linux for development, so that would take me quite some time to test.



Indeed the project is quite unusual:
- It is symfony framework bundle, which means that the project structure is somewhat inverted (root directory is root of a bundle and, root of the application is inside the vendor directory)
- It is long running - the script is usually running many minutes, sometimes even hours. Hitting a breakpoint may sometimes take tens of minutes.
- As mentioned above, having huge number of watches or large immediate statements definitely make the things worse
- I think it started with version 6 of the debugger which fixed an issue with stacktrace line numbers - but I'm not too sure about this - it is long time ago, though i might be able to look it up more precisely if someone were truly interested
- The code does not have any encoded/protected/compressed files, it is just regular PHP. It heavily uses objects, but does not occupy obscene amounts of memory (around 30M usually)
- As for the activities - most of my breakpoints are in places of failure (exception handlers, "unreachable" code etc.) and it mostly goes like this - the script is running for 10 minutes, then an exception is raised, it enters an exception handler, hits the breakpoint, and then there are two outcomes:
1) either it takes about 3-5 evaluated expressions or immediate statements and the error appears. It is interesting that it does not seem to matter what statements are evaluated, it feels like hitting a limit - it does not matter how the limit is hit.
2) or it works - and I mean it really works - I can be stuck in one debugging session for 1/2h and it won't terminate.

So yes, it is quite random. But it appears quite a lot - I would say 8 out of 10 debugging session end this way. And if the error appears then it will appear again on next same HTTP request, restarting server/phped does not help. All that helps is either rewriting the code (even the one which is not causing an error) and/or doing what I suggested in the second post (which obviously does not work, because Mr. Knowall said so). Also the debugger may fail with some other error messages, which behave exactly the same, so i forgot them. I had them screenshoted, but I deleted them few months ago.

<all personal and unrelated ranting is cut, do not proceed with that and take what I said above as joke, it's what it was>

"session prematurely finished" means that the client has disconnected from the server or server has crashed. If you use 5.5, most likely you'll find some notifications about core dump/sig ill/sig segv or another fatal problem(s) in apache error_log. It means that php 5.5 stability leaves much to be called good. What do you expect from a 1 year old stuff?
Another possible reason for "prematurely finished" is your network. It's known that all TCP connections passed through NAT routers are stored in its memory. If router memory exhausted, it has to drop some connections to leave space to new ones. Old routers can hanrdly handle more than 200-300 simultanous connections at a time. Similar problem is network performance. If server does not respond to the client within 30sec, connection will drop. Try to evaluate sleep(40) in immediate and you'll see this.
I recommend to try with local server to see if it fixes the problem.
Finally, most modern AntiViruses has built-in firewall which is known to snoop into the network connections and may interfere with debugger especially if you didn't configure AV properly. Try to UNINSTALL it to see if it helps. I know at least ONE commercial firewall that breaks network.

Well, the apache worker process is restarting and logs only "Parent: child process 10968 exited with status 1 -- Restarting.". The trouble is that no such things happen when the request are run without debugger - that is when I "Kill the debug session" from the firefox panel what previously failed to run, runs without problem.
All this happens on a local server, we don't do any debugging on remote servers. I use a Comodo firewall, but both local computer address and PHPed are fully trusted.

I can only recommend you to switch to php 5.4. It's known to be quite stable. 5.5 is known to be unstable.
If you have a sample reproducing a problem with 5.5 and you share it with me, I'll tell you for sure where the problem is.