• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

PHP simply stops executing

digitalpoint

Well-known member
#1
Has anyone run into an issue where PHP simply stops executing at a certain point? No errors, no Apache segfaults or anything else. The browser gives a message after 30 seconds that the server stopped responding.

In the most simplistic form, it's this...

PHP:
function getsomething () {
	echo '2';
	return;
}

echo '1';

$somevar = getsomething();

echo '3';
You would expect an output of "123"... instead I get "12" and then just everything stops running/responding.

The real-world example of it happening is when someone starts a new conversation in my XenForo install (nowhere else that I've noticed). The conversation gets inserted properly via the save DataWriter, and I know it gets to the return portion of that method because I setup some debugging code that outputs properly. But it never *actually* returns, so XenForo gives the error that the server stopped responding and to try again (but the reality is that the conversation was actually inserted properly).

I've restarted web server, DB server, disabled all listeners, overwrote all XenForo files to make sure nothing was altered. I've even gone so far as to make the save() method a "final" function in case there was something else somehow extending it and hanging it.

From tracing/debugging it, I'm fairly certain it's not a XenForo bug, but rather something weird going on with my server. Just wondering if anyone has ever seen anything like this?

Again... no Apache crashing, segfaults, errors or anything else.
 

Deebs

Well-known member
#2
Shawn,

Not seen anything like this at all. Can you provide a simple self contained PHP file which creates the problem?
 

digitalpoint

Well-known member
#3
Well I don't think it's something that can be reproduced normally... whatever it is I think it's something specific to my server somehow. I copied the XenForo database and copied all the XenForo files to a different location on the same server and I don't see the issue.

The only thing I can think of is maybe XCache is doing some sort of crappy hashing based on file path and just mucking it somewhere along the way.

That's why I'm so confused with this one... I do a LOT of PHP work and I've never seen something like this before. Using the latest stable versions of everything (Apache, PHP, etc.)

Going to try moving stuff to a different web server (but same file path) and see what happens. Then maybe start uninstalling PHP modules (I only have a couple... XCache, memcache and geoip) and see if I can narrow down wtf is causing it.
 

Deebs

Well-known member
#4
If you want me to install it on a nginx server with php 5.3.5 to test just shout, happy to give it a go. I do not use xcache but APC.
 

digitalpoint

Well-known member
#5
Eh... I'll do what I can to try and narrow it down first. It's just a bizarre one... No errors from the server or anything... the AJAX request just times out after 30 seconds, but internally the conversation gets created.



 

digitalpoint

Well-known member
#7
hehe... fixed.

BTW - I forgot to mention I gave it a go with jQuery 1.6.4 instead of the default 1.5.2 just to see if there might be something funky in the older versions (since it's jQuery doing the actual AJAX request), but was the same...
 

digitalpoint

Well-known member
#9
Nope... in fact, the DB connection stays active (but idle) to the DB server for 30 seconds (until the HTTP request just times out). As I said... it's totally bizarre. It literally returns from a function, but doesn't execute the next line of code after the return and no errors, segfaults, SQL issues, etc.
 

SneakyDave

Well-known member
#10
I think I had a similar problem (but with nginx), but it was some kind of MySQL corruption on an InnoDB table and transactions weren't being comitted, but I saw errors being logged about it pretty quickly.
 

digitalpoint

Well-known member
#11
I went and double checked (even though I did before).. nothing in the error log... the slow query log shows a query from it... although I suspect it's just from the transaction never actually being committed...
Code:
# Query_time: 30  Lock_time: 0  Rows_sent: 0  Rows_examined: 0
UPDATE xf_user SET
conversations_unread = IF(conversations_unread > 1, conversations_unread - 1, 0)
WHERE user_id = '1';
It's pretty obnoxious...
 

CTXMedia

Formerly CyclingTribe
#13
I have a similar "stalling" issue with my server and have always just assumed it was related to Sphinx running at 15 mins. intervals doing its indexing - you know, hogging resources and causing transaction bottlenecks/queue tailbacks whilst everything else is still going on around it. That's just my laymans guesswork though, but I never had it before we move to IPB + Sphinx.

Do you use Sphinx at all?
 

digitalpoint

Well-known member
#14
We use Sphinx, but different site and on different server. This is not Sphinx or any other resource hog bottleneck. My servers peak at about 5% utilization when under heavy load.