It looks like this specific test case is causing a stack-overflow due to the call depth, via the recursive call in excimer_log_find_or_add_frame which tries to traverse the prev_execute_data. There is a guard for the depth, but only when maxDepth is set, which is default 0. I don't believe there's a simple way to detect the max call depth. I wonder if it would be better to just add a default depth, of say, 1000, and allow people to set it to 0 if for some reason they _really_ need to do that.

This is the backtrace in the core dump:

FYI I've been following along here, and I checked out the excimer build - super cool, worked well for me! I just had a question around the scope. When I tried it I noticed inbuilt PHP functions were not part of the sample, so if I have a function that calls sleep or curl_exec, I don't see this as part of the sample. I assumed this is because inbuilt functions use a different API. Is there plan to include inbuilt php functions in the samples?

If I understand the above numbers correctly, this is using xhprof_enable, which is orders of magnitude slower than xhprof_sample_enable. We're only using the latter. I'd recommend testing xhprof_sample_enable before looking at an out-of-process approach (incidentally I have tries this in the past with dtrace or similar to use os level markers, but never made good progress.)

I thought it would be good to share an update as I've been working on our XHProf rollout this week.