I was wondering if there was a way to know where the script stopped (ie: file + line), which would be useful for debugging or for removing stupid 'exit' calls lost somewhere in the code.
Thanks in advance
Wrong (and I'm sorry for not testing it first): You could use register_shutdown_function in conjunction with debug_backtrace.
See here for a duplicate of your question: Fastest way to determine where PHP script exits .
If you want to remove exit from the script, try using PHP Code Sniffer PEAR package http://pear.php.net/package/PHP_CodeSniffer
Just create a sniffer to find out where all the exits are in the code (you get a report of file and line).
If you want to find out what line a script stopped at, use a debugger and you can get a stack trace to find out the last line a script executed too (Xdebug is easy to use and set up). Any debugger is going to severely hinder performance as it needs to manage more memory.
I'm not sure what IDE your using (if any), but this would be trivial using xdebug. I personally use it with netbeans and it works great although it is a bit tricky to setup. It will let you walk through your code step by step and show exactly where it is exiting.
Related
I've got some quite complicated php website and after some changes I'm getting 'white screen of death', I'm pretty sure its some die; exectued somewhere.
Is there any way to show file and line of code where die; was executed?
[edit]
To response answers here - it's not about finding all dies in entire project. It's about showing witch one was used during some specific execution. It's becouse sometimes (usually with frameworks like mvc) it's not so easy to know what php files were used.
Your IDE supports text search as others already pointed out. As an alternative, use grep. A command like grep -rnwI die * in the root of your source folder would help you along a bit.
Also, if you haven't done so already, enable error_reporting and display_errors. That way you won't have to guess whether a die(); or exit; is still there.
Just configure your project in any IDE like Netbeans or Eclipse and then you can use the FIND feature inside it .
Simply search for "die" then IDE will let you know all the files having words "die" along with their line numbers.
Hope it helps...
use some of the tools like netbeans press ctrl+F to search the value in your project
I have been tasked with setting up a website on various environments for different stages of evaluation (dev/test/staging/etc).
On our staging environment however, it seems there is some difference preventing the PHP script from finishing, so the page is never delivered to the browser.
I'm wondering if there is a way I can output to log some sort of stack trace or backtrace upon cutting the connection, or is there some other method to find out what exactly PHP is doing at any given point in the script's life cycle?
It's a Drupal site, so it involves a lot of code I'm not familiar with, and could take hours to sprinkle die; commands throughout to see where the script is loading to.
I understand I should probably be looking at the differences in environments, however all should have very similar configuration (Ubuntu 11.04) and the staging environment seems entirely happy to serve other PHP sites whilst this particular site is refusing to finish. If anything this staging site has more resources available that other environments which are not having problems.
UPDATE: Sorry all, found the problem in the end. The staging environment was on a VLAN that was not permitted to access itself via public IP, and for whatever reason (still confused about this) it was trying to access itself as part of the page load and never completing the request. Setting a hosts file entry for 127.0.0.1 fixed the issue.
Debugging an issue like this step-by-step using a tool like xDebug is an option, but will probably take a long time -- finding where to put the breakpoints is going to be on about the same level as working out where to put die statements around the code. The debugger option is a better way of doing it, but won't save much in comparison, when you have a problem like this where you have an unknown blocker somewhere in large amounts of unknown code.
But xDebug also has a profiler tool which can show you what functions were called during the program run, how long they took, and highlight where the bottlenecks are. This will probably be a better place to start. Just configure xDebug to generate a profiler trace, and then use kCacheGrind to view the trace in a graphical environment.
If your program is getting stuck in a loop or something specific is taking a long time to complete, this will pinpoint the problem almost straight away; you'll be able to see exactly which function is taking the time, and what the call chain looks like to get to it.
It's quite possible that once you've seen that, you'll be able to find the problem just by looking at the relevant code. But if you can't, you can then use xDebug's step-thru debugger to analyse the function as it runs and see what the variables are set to to see why it's looping.
xDebug can be found here: http://www.xdebug.org/
Use xDebug.
Its very easy to install and use.
it has few options like breakpoints and step by step to track status of PHP script before finishes loading
and you can download xDebug from here http://www.xdebug.org/
step by step tutoril for set up xdebug is availble at sachithsays.blogspot.com/
I want to log what lines per file was run in php. Xdebug can do that, thats all I know. How to do this?
I guess you want a code analyzer, here is a good thread about this
Oh my goodness. I never thought that I will need to ask you this. But unfortunately yes, I need to!
I have a PHP written script of my own that uses ffmpeg-php. And ffmpeg-php is a bastard. For some input it works ok, but for some it crashes my whole PHP and server throws Internal Server Error 500. I've tried several times to update ffmpeg-php, ffmpeg itself and so on, but when for some input it works in version 0.5 in 0.6 it wont work. And what i need is be sure that rest of the script will be processed correctly. And now it does not, because when it comes to run toGDImage() on movie frame I have Internal Server Error 500 and no feedback why from any source.
So for peace of mind of my users I decided that I need to isolate this part of script that messes with ffmpeg-php. I need a way to assure that if something will go terribly wrong in this part, it rest will go on.
Try catch does not work because this is not a warning, nor a fatal error, it is a horrible server-disaster. So what are your suggestions?
I think about putting this script into another file called ffmpeg-php-process.php and call it via HTTP and read result, if it is Internal Server Error 500 - I will know that it was not ok.
Or are there any other, more neat ways to isolate disaster scripts in PHP?
Ps. Don't write that I need to diagnose or debug or find the source of the error. I'm not a damn beginner and I'm not a ffmpeg dev to mess in it's code, I need to make my users safe now, and it's everything that i care now.
If you're getting a 500 error, it's because an exception of some sort is being thrown at a level lower than that of PHP itself. Unless your code is spinning into some kind of infinite loop or hitting a recursion limit (and especially since it worked with version 0.5), there's a good chance that ffmpeg or ffmpeg-php is crashing and taking the instance of PHP that launched it down with it.
Frankly, there's nothing you can do from PHP.
Your best bet would be, since you've already got access to the server, to write the script in question using a language like Python. There's a ton of ffmpeg python plugins, so you shouldn't have a difficult time setting that up at all. Call your Python script from PHP and pull in the output from a file. What this will do is isolate PHP from your script failing. It'll also get you away from ffmpeg-php (which, at least to me, seems like an unholy combination).
If you're dead-set on using PHP (which I don't recommend), you can launch another PHP script using php-cli from your outward-facing PHP script and do the work from there (as you would with Python). Again, I highly recommend that you avoid this.
Hope this helps!
You could spawn a new process containing your php-ffmpeg script. There are some functions to do that: proc_open() as instance.
The documentation has a not bad example about it:
http://php.net/proc_open
I have something similar going with a convoluted, large, bulky legacy php-email system I support. When it got apparent that the email system was becoming it's own beast, we split it off as its own virtual server entirely. There's no separation like PHYSICAL separation. And hey, virtual servers are cheap....
On the plus side, you can start, restart, and generally destroy the separate server with little affect on the rest of your code. It may also have improved backup implications (isolate media and logic) Since going this route, we've not ever taken the main application server down.
However, it does create a connection challenge as now rather than working local you're going to have your server talking to another separated by at the very least a bit of wire in the same cabinet (hopefully)
Anyone got a problem with php 5.2.12 getting a lot of " Maximum execution time" error when trying to include() files?
I can't seem to find the bug in php.net, but it's consistently giving us that error on numerous scripts.
Anyone can recommend solutions?
The same script runs on a few other servers with php 5.2 without any problems. So just to let you guys know it isn't a script problem.
This is much, much more likely to be a problem with your code rather than with a specific version of PHP. PHP by default has a maximum execution time of 30 seconds, which you can modify by calling set_time_limit() or adjusting your php.ini settings.
If you're not doing something that you expect to take a long time, then usually the cause of this error is an infinite loop somewhere in your code. I'd throw a debug_print_backtrace() and a couple of exit() calls into some key locations and try to figure out which file is giving you grief, and then take a closer look in there. Perhaps you're stuck in an infinite include() hierarchy, in which case you should be using include_once() for all your class and function library files.
I would check to make sure the same include isn't getting requested time and time again somehow. You might try include_once() just to see if it changes things for you. That isn't a solution so much as it's a potential temporary fix. You should find out what is causing this if indeed it is getting called over and over again.
If you have xdebug setup and an IDE that supports debugging this would be a great way to dig into the code.
Otherwise, can you try putting some output statements in the first line of the included file and in the line PROIR to calling the include. See what's going on ...