500 error with Wordpress

[johnleach]

Hi, I'm seeing a 500 error returned in Wordpress. It is fixed with either a restart of the php fastcgi processes, or clearing the xcache cache from the xcache admin page.

It is not with all Wordpress pages, so far I've seen it when posting a comment. Posting comments works fine for a few hours/days then consistently returns a 500 error.

This is with php5-cgi 5.1.2-1ubuntu3.4 package on Ubuntu Dapper running as a fastcgi process under lighttpd. It's with xcache 1.1.0 compiled from source (and observed from at least xcache trunk svn r262).

I get no error output from php (to the error_log or php stderr) when accessing the broken page (though I know php error logging to be working).

I think the php script causing the problem is wp-comments-post.php but I've got a couple of comment related plugins installed, such as Akismet and a threaded comments plugin.

I've got other Wordpress installations on the same box which *reportedly* had the same problem (but at different times), though I've not seen it myself.

I'm getting no coredump on the error.

root@mule:~# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --with-tune=pentium4
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

root@mule:~# php-cgi -v
PHP 5.1.2 (cgi-fcgi) (built: Nov  2 2006 12:24:48)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with XCache v1.1.0, Copyright (c) 2005-2006, by mOo

[johnleach]

Tested with the latest trunk direct from svn (r277) and still produces the 500 error.

[johnleach]

More info that might be useful:

[xcache]
xcache.size =                  60M
xcache.count =                 2
xcache.slots =                8K
xcache.var_size =              10M
xcache.var_count =             2
xcache.var_slots =            8K

xcache.test =                Off
xcache.readonly_protection = Off
xcache.mmap_path =    "/dev/zero"
xcache.coredump_directory =   "/tmp/xcache"

xcache.cacher =               On
xcache.optimizer =           On

[xcache-common]
zend_extension = /usr/lib/php5/20051025/xcache.so
auto_globals_jit = Off

[xcache.coverager]
xcache.coveragedump_directory = "/tmp"
xcache.coveragedumper         = Off

Would it be worth testing with xcache.count = 1 instead? The box is a single hyperthreaded CPU so I chose 2. I unfortunately can't afford any more down time on this box, but I really need to set up a separate staging server anyway.

[moo]

nope, u don't need xcache.count = 1, can u pls try if trunk r282 fixed your problem?

[johnleach]

500 error again on wp-comments-post.php on trunk r287. Again, apologies for the delay but it just takes quite a while before the crash happens, and I keep having turn disabled xcache whenever I'm not available to fix after the crash (over night when I'm asleep for example :)

This time I tried a few things before restarting php. I edited the wp-comments-post.php and added a die function near the top, and moved it down line by line and re-POST-ed to see where it was crashing.

I narrowed it down to line 51 ($comment_id = wp_new_comment( $commentdata )).

I followed that into wp-includes/comment-functions.php but as soon as I added a die to that script, this whole Wordpress install started giving 500 errors. Reverting the code back didn't fix. Adding dies to wp-comments-post.php showed that it was NOW crashing at the first line of PHP. Truely fscked.

Other wordpress installs on the same box sharing the same fastcgi PHP instance didn't seem to be affected, but I didn't have time to check thoroughly.

I've tried to reproduce this on a qemu clone of the server but haven't been able to trigger the crash. I don't think my automated test is POSTing to the script correctly tbh.

This is on a production server so I can't do any more tests, sorry :( I'll see if I can manage to reproduce on the qemu clone if I can get time.

Thanks for your help and hard work.

[moo]

thanks, as the problem u got is rare, i may push 1.2.0 (which i stated it unstable) before this bug is fixed

[moo]

see  http://forum.lighttpd.net/topic/4863#6132, pls set "xcache.coverager = Off" and try again

[johnleach]

I compiled 1.2.0 with "--disable-xcache-coverager" and disabled in config (just in case :). It's been in use for 3 or 4 days now without the usual 500 errors, so this looks to have fixed the problem.

Thanks for your help. Sorry I couldn't try this earlier!

[johnleach]

the 500 errors are back as before (largely just on a POST to wp-comments-post.php).

This was with the coverager disabled at compile time and runtime (just in case).