views:

178

answers:

5
+2  Q: 

Debugging hung php

I have a php web application that is occasionally hanging. When I navigate to the page it will just sit there trying to load for hours, even though max execution is 210. This is an application uses curl behind a proxy to download stuff. Error reporting is set to all, but that dosn't matter since the page is blank and hung. I can not find anything on debugging a hung php process. PLease help!! Thanks!

+2  A: 

Last i checked, HTTP/IO operations happen outside php time, so its possible the CURL is dying or timing out.

Its IO, so php just throws out to some system library and then calls "select" to wait for it to come back.

If it doesn't come back.. php code won't even be looping and thus wont even know its not coming back.

Kent Fredric
+1  A: 

i would bet money on it being a curl issue. i had a similar problem a few years ago with a particular curl option i added, which hung the script on occasion. i wish i could remember exactly what the issue was, but i believe it ended up being that curl was linking to a wrong library underneath. (edit) actually, i'm pretty sure it was the SSL library in my case, in that curl was using an older version of openssl.

i'd suggest removing all curl_setopt() calls first of all, then adding them back in to see if you can isolate the error. i think if you run the equivalent curl command on the command line, you may see the error there immediately.

i fixed it by updating the openssl library curl was using.

Owen
+1  A: 

to see what is happening behind the scenes, you could install xdebug, then enable triggered profiling (?XDEBUG_PROFILE=1)... it will output a log to the filesystem compatible with kcachegrind/etc.... that you can use to see where execution is hanging.

of course, it is MOST likely a curl issue....

Jason
A: 

Xdebug is a great idea, and if it doesn't help, I'd also recommend running your webserver through ktrace, strace or truss. It shows you exactly what it does and where it could be hanging.

It sounds like there is a temporary connectivity issue, or something else that your application relies on is blocked.

In case you use Apache, please check the Apache HTTP Debugging Guide. The guide is a bit *nix-centric, but can be applied to any webserver.

On top of debugging your webserver, I'd also recommend adding checks if your proxy is up/responsive at all times and the download source is always available. Those checks could be added using a tool like nagios or a 3rd party service like Pingdom. Last but not least, it could be a temporary DNS issue as well so you could go about using IPs to connect to the proxy and the download source and/or add monitoring for the DNS service.

HTH

Till
A: 

This is going to sound lame, but just open a file handle at the very start of your page request, then start doing fwrites to /tmp/debug.txt . See where the last one gets written, and then start echoing various variable values out into the file in that area. Use the theory of binary search to distribute your fwrites into finer and finer sections of resolution on your code.

i.e.

$fh = fopen("/tmp/debug.txt", "w");

fwrite($fh, "made it to here 1 \n");

//some code

fwrite($fh, "made it to here 2 \n");

//more code

fwrite($fh, "made it to here 3 \n");
Zak