OK, adding breakpoints to the generated Twig view made me find the error: a memory exhaustion due to a recursive function call in an entity:

    public function isSubscribed() : bool
    {
        return $this->isSubscribed();
    }

Instead of:

        return $this->isSubscribed;


Now, a few questions remain:

- I'm surprised I didn't get a line in the php-fpm error log; is this expected in this case?

- I guess the segfault occurring when memory is exhausted is a bug; should I file a bug with Blackfire?

> I'm surprised I didn't get a line in the php-fpm error log; is this expected in this case?
> I guess the segfault occurring when memory is exhausted is a bug; should I file a bug with Blackfire?
Running out of memory doesn't cause a segfault, but a stack overflow does. When that happens the kernel will kill PHP immediately without giving it a chance to do anything like write to a log.

Stack overflows tend to be really easy to identify from a backtrace because (a) it's absurdly long and (b) it's mostly the same few lines repeated over and over.

The segfault points to blackfire.so because that it what was under the hood performing the function calls. You know, the thing interpreting and running your PHP code. So as a human developer who knows more about your application than the kernel, it's up to you to find out where the real problem is. Xdebug is good for that as it can impose a limit on how far down the stack goes, which means that when it quits you can a backtrace very much like GDB's - but shorter, and showing the call stack in terms of PHP code. Unfortunately it doesn't seem like you can run Blackfire and Xdebug at the same time.

As far as PHP is concerned, we don't consider this a bug for you to report and us to fix. After all, the issue was your recursive function. Obviously I can't speak for Blackfire but I expect they would feel the same way.

Thank you for your explanation, and sorry for reporting something that's not considered a bug.

I'm surprised though, as I was pretty sure that PHP imposed a hard limit on how big the call stack can become?

A recursive function call like this being so easy to trigger, wouldn't it be nice to give PHP a chance to write something to the logs when it happens?

> I'm surprised though, as I was pretty sure that PHP imposed a hard limit on how big the call stack can become?
Generally not. There would have to be some configuration option to specify how much, but then people will just set it to a high number and never think about it again lest they accidentally trigger it with valid code. There's also no clear number one can set it to: environments don't all have the same configuration or amount of memory available, so a limit that works in one place may not help another.

As far as PHP is concerned, segfaults due to infinite recursion are considered user error. There are a couple exceptions to that, I believe, but I don't know exactly what they are.

Setting a low time limit, like a couple seconds, can sometimes catch infinite recursion. It helps mostly when there is some non-trivial amount of code being run before each recursive call, in which case PHP hits the time limit before the process hits the stack limit.