Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently updated a Debian Lenny server to php 5.3,5 using the dotdeb source. Soon after doing so certain (but not all) sites on the server stopped responding to requests. A blank response would be returned - no headers, no content, nothing.

I found this related question on stackoverflow which seems to describe something similar and used the same code the user had in their answer to see if I could replicate the issue:


class A {
    public function __construct()
        new B;

class B {
    public function __construct()
        new A;

new A;

print 'Loaded Class A';


This triggered the problem - the page returned absolutely nothing despite the original question stating this was fixed in PHP 5.5.0. No CPU block as you'd expect, no wait, just an almost instant zero response.

I then ran this same code from the cli (php -f test.php) and the only output I got was 'Segmentation fault'.

Tailing the kernel log I've spotted:

Feb 16 07:04:06 creature kernel: [192203.269037] php[17710] general protection ip:76ef37 sp:7fff155e9bb0 error:0 in php5[400000+870000] Feb 16 08:57:31 creature kernel: [199639.699854] apache2[31136]: segfault at 7fff13a84fe0 ip 7f730514ea40 sp 7fff13a85008 error 6 in[7f7304ce8000+915000]

All extremely odd and I'm not sure what it's pointing to/what I should do to debug this further. As I said some sites work but code such as the above definitely trigger it. Not that the sites I want to server have code like that - it's just an example.

Any help is much appreciated!

share|improve this question
up vote 0 down vote accepted

Looks like it was down to Suhosin. Disabled it as a php module and things are working fine again.

share|improve this answer

For future reference, you usually want to enable coredumps on the process using ulimit -c unlimited, then run the produced core dump through gdb to get a backtrace from it. Sometimes you can also use ltrace to trace library calls, though this method gives you less useful information.

share|improve this answer
Indeed, useful to know - thanks! – Joe Feb 17 '11 at 14:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.