Support » Fixing WordPress » Premature end of script headers: index.php

  • Hello,

    when accessing various portions (no pattern visible, but I’ve tested categories mainly) of my blog I get the following error. I’ve changed the domain (for now) but everything else in as it was returned from the server. Software versions are there, too.

    I’ve scoured the web including (of course) for possible solutions and I’ve tried a few. What I haven’t tried is contacting the host about e. g. the php memory limitation in Apache (unfortunately I’m stuck with the host and the host is rather uncooperative). So, what I’d be looking for would be…

    ..a way to either optimize the code to fit the possible memory problem (and a way to actually profile the process without shell access, if that’s possible; I _am_ able to go in with phpshell, although I haven’t tried what kind of stuff I can do with that access – I’m pretty sure it’s limited)

    ..a fix to the problem that is causing this within WordPress, _if_ it is within WordPress

    ..any other help that you may have (excluding praying, mad rituals or sacrificing my firstborn, please)

    Server error!
    The server encountered an internal error and was unable to complete your request.
    Error message:
    Premature end of script headers: index.php
    If you think this is a server error, please contact the webmaster.
    Error 500
    Wed Jan 31 23:17:02 2007
    Apache/2.0.55 (Debian) mod_jk2/2.0.4 mod_python/3.1.3 Python/2.3.5 PHP/4.3.11 mod_perl/2.0.2 Perl/v5.8.8

Viewing 5 replies - 1 through 5 (of 5 total)
  • Try chmodding your folders 755, and files 644 once? Or, try what this person did.. Good luck!


    I’m having same issue with my hosting company. I checked file permissions and they are all 755. any other suggestions?

    Could be a problem with mod_suexec or mod_suphp. If you have access to the error_log or suphp_log you can find further information there (if you find the “premature end…” there and don’t know what the other errors right before that one mean, post them here). If not, try a phpinfo() and check the modules section (or post it here).
    A link to your page would help too, so one could check which parts work and which not. If it is a suexec/suphp problem it is most likely that some of your template files dont have the right owner or group.

    TimoK, thanks for reply. I can’t see those modules enabled on the server. Actually, I can’t see the full list of enabled modules on phpinfo(). I think, this is issue is also effecting that. Another issue is,

    This problem is occuring under;
    As soon as page is loaded, server throws Internal Server Error (500) I added another page to cover this error for now. I played with php.ini file to increase mem limit per script to 32M but no help. The weird thing is even I run those php scripts through shell directly with php index.php, I get ‘Segmentation fault’ error. When I run it in interactive mode, I get ‘*** glibc detected *** double free or corruption (!prev): 0x09b7ff28 ***’ so I’m not sure where how this issue might be resolved.

    I get ‘Segmentation fault’ error. When I run it in interactive mode, I get ‘*** glibc detected *** double free or corruption (!prev): 0x09b7ff28 ***’

    I am getting these errors too with a WordPress related cron job I’ve made (cron run like ‘* * * * * php /path/to/file’). The cron includes wp-config.php so that the script has access to $wpdb, but while the cron seems to run OK, the emails I get (due to MAILTO=… in the crontab) were containing ‘/bin/sh: line 1: 32682 Segmentation fault’ stuff (though that only happened a few times and I can’t repeat it), and now contain (repeatedly, every time):

    ‘*** glibc detected *** double free or corruption (!prev): 0x08493740 ***’

    I was able to trace this to wp-settings.php and then to wp-includes/wp-db.php, and then to:

    if ( ! isset($wpdb) )
    	$wpdb = new wpdb(DB_USER, DB_PASSWORD, DB_NAME, DB_HOST);

    If I delete this, the glibc error goes away. Of course then the script itself can’t work.

    The error doesn’t happen if in the cron I use ‘wget’ instead of ‘php path/to/file’. So I’m using wget instead to run the cron.

    I even tried changing DB_NAME to another database on the server, but that didn’t suppress the glic errors.

    Anyone have any idea on this? Why would ‘wget [scripturl]’ have no errors but ‘php [scriptpath]’ does?

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Premature end of script headers: index.php’ is closed to new replies.