Opened 7 years ago

Closed 11 months ago

Last modified 11 months ago

#53 closed defect (worksforme)

500 error with Wordpress

Reported by: johnleach Owned by: moo
Priority: major Milestone: black hole
Component: coverager Version: 1.1-dev
Keywords: wordpress, 500, comments Cc:
Application: PHP Version:
Other Exts: SAPI: Irrelevant
Probability: Blocked By:
Blocking:

Description

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

Change History (13)

comment:1 Changed 7 years ago by johnleach

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

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by moo

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

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by 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

comment:6 Changed 7 years ago by moo

  • Milestone changed from 1.2 to 1.2.1

comment:7 Changed 7 years ago by moo

  • Component changed from cacher to coverager
  • Status changed from new to assigned

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

comment:8 Changed 7 years ago by 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!

comment:9 Changed 7 years ago by 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).

comment:10 Changed 7 years ago by moo

  • Milestone changed from 1.2.1 to 1.2.2

comment:11 Changed 2 years ago by moo

  • Milestone changed from 1.3.3 to undecided
  • pending set to 0
  • SAPI set to Irrelevant

comment:12 Changed 11 months ago by moo

  • Resolution set to worksforme
  • Status changed from assigned to closed

closing this bug unless this bug can be reproduced in 3.0.x

comment:13 Changed 11 months ago by moo

  • Milestone changed from undecided to black hole
Note: See TracTickets for help on using tickets.