# [SOLVED] Debugging Apache segfaults

## jsfan

My Apache is segfaulting when certain PHP code is executed, it seems.

I have seen that there are lots of other forum posts around this problem and

basically they all suggest to make sure that all Apache modules are up-to-date.

However, I've already done that and disabled whatever I could basically only leaving PHP5

running. Still no luck. Also, an

```
emerge -eD apache
```

did not make any difference.

Now I'm wondering how I could debug that. I tried to set my ulimit to unlimited but

I can't find a core dump anywhere. My big problem is that this occurs on a productive

system which I cannot easily migrate somewhere else until I have fixed this.

Does anyone have suggestions how to debug this? I'm sorry if this is a stupid question but

I really can't think of any way.  :Sad: Last edited by jsfan on Fri Sep 21, 2007 1:11 am; edited 1 time in total

----------

## Hu

If it only crashes when some particular page is requested, it should be possible to start the server and attach a debugger before it crashes.  When you request the offending page, the process will be signaled and the debugger will break in.  You can then examine the process state or save a core file (with gcore).  Once you have broken in, you should be able to get a stack backtrace, which may help you identify the problem in more detail.

See How to get meaningful backtraces in Gentoo for instructions on how to prepare the system.

----------

## jsfan

But if I run Apache in the debugger, will it cope with the forks? The server is usually under heavy load and before I manage to request the offending page, I might have had dozens or even hundreds of other requests. I'm a bit concerned about increasing the load to the edge of DoS if I run Apache in gdb.  :Sad: 

----------

## Hu

It might not be good to put a debugger on a server under that serious a load.  You could try changing the value of /proc/sys/kernel/core_pattern to point the core files to a directory that can be written by the Apache user, such as /tmp.  You will still need to ensure that the ulimit is sufficiently high, of course.

----------

## jsfan

Maybe I'll try that. Thanks for the hint. Unfortunately I'll have to reboot for that. grsecurity locks my kernel flags...

----------

## jsfan

Because I couldn't get the core dumps to work (Apache claims to write one to /tmp but it's not there),

I decided to go with gdb. What I tried is to attach to a running process and then hope that this process

would segfault after a while. However, so far it always died a normal death while I could never catch the

threads that segfaulted.   :Sad: 

How can I make sure I catch the segfaults without having to configure Apache to spawn no more than one

thread? Spawning only one thread would be a big problem because of the heavy load the server is under,

anyway...

----------

## jsfan

I've found out what PHP script is causing the segfault. I've disabled it for now but will have to debug it at some point.  :Smile: 

----------

## Hu

In general, scripts should never be able to cause their interpreters to segfault.  If it is, it represents a bug in the interpreter.  Once you find a reproducible and minimal test case, please report it to the PHP maintainers so they can patch the interpreter.  It is acceptable for the interpreter to reject a script, but not for the interpreter to crash while processing the script.

----------

## jsfan

Yes, I thought the same about a script not being able to crash an interpreter. Unfortunately this all happened in a extension of the CMS TYPO3. So it might be rather hard to track down what actually triggered the problem and find a minimal test case. But I'll try my best.  :Smile: 

----------

