Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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'm trying to debug a segfault in PHP/Apache running on RHEL4.

This is a production server, so I'm trying to install a separate copy of apache and php, and run apache through gdb.

When I load httpd through gdb and then do run -X, I get the error (no debugging symbols found)...Error while reading shared library symbols: Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.

The Apache manual says something about setting EXTRA_CFLAGS to "-g", and i've tried configuring with --enable-maintainer-mode, but I don't seem to be getting far.

share|improve this question
up vote 3 down vote accepted

It would be difficult to debug a complex multi-process/threaded network daemon application like Apache, complete with modules (such as potentially including mod_PHP) via gdb.

Why do you think the error lies within Apache's httpd, and not either an application (i.e. a PHP script) or module (e.g. mod_PHP)?

What is the exact segfault error message?

Does the segfault occur on startup, after a random while, after a certain web app is run, or a particular amount of time (about every 48 hours)?

Have you increase or added the Apache httpd Log Level directive in the Apache configuration file to get more information? Try info or debug for the most information.

I've been using Apache httpd for nearly 15 years, and I have never had to debug the Apache web server daemon itself, so I'm surprised you appear to need to debug it using gdb.

(no debugging symbols found)

This means that the debugging symbols are not included in the binary executable. Typically the compiler didn't have debugging enabled (-g flag with gcc), and/or the install process stripped the executable file, to make it occupy less memory while running.

Error while reading shared library symbols:

This error is about the shared (dynamically linked) libraries debug symbols.

Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.

I haven't seen this error before, it may be occurring because Red Hat Enterprise Linux 4 is built differently. DWARF is a debugging information format. The other common format found on Linux systems is Stabs. Basically seems to be suggesting the shared libraries are also "stripped" of debugging information.

Correction: It means that debugger (gdb) cannot read / find the string pointer (strp). It may be due to GDB Bug 7358 or a compiler / debugger version mismatch.

The shared libraries often have the debugging information (symbols) in a separate package. For example, I believe RHEL the GNU Standard C Library (glibc) debug info is in a package called glibc-debug. You will need to install the debug info of the libraries that Apache httpd uses. Check the Apache rpm package's libraries dependencies for a list of libraries the executable depends upon -- rpm -qR package-name or rpm -qpR <rpm-file>.

i've tried configuring with --enable-maintainer-mode, but I don't seem to be getting far.

I'm sorry, but that's too vague to help you with. You need to include more useful details.

Update: Usage of automake's maintainer-mode is mostly for packaging or development, not debugging proposes.

Consider using a PHP debugger, like Xdebug with the PHP application or script.

Summarize comments

I'll try to summarize the information from the comments here:

  • Generating a gdb backtrace (from PHP)
  • requires PHP built with debugging (symbols included)
  • PHP with debugging can be built by making it using EXTRA_CFLAGS="-g" make or
  • Preferably by using configure --enable-debug (ref), followed by make

This appears to have resolved the debugging symbols.

share|improve this answer
This is the way the PHP documentation recommends debugging segfaults from a PHP script. Basically I have a PHP script which is intermittently crashing, and apache is leaving this in its logs: [notice] child pid 20242 exit signal Segmentation fault (11), possible coredump in /etc/httpd – blockhead Mar 21 '10 at 1:12
As far the -g flag for gcc, I've tried to add that either as an environment variable (export EXTRA_CFLAGS), or by adding that to the make command (make EXTRA_CFLAGS="-g"), and I still can't get it to work. Obviously, I don't really know what I'm doing. – blockhead Mar 21 '10 at 1:14
maybe take a closerlook at the php code, and php apache module first. – The Unix Janitor Mar 21 '10 at 17:21
From the PHP generating backtrace information, second paragraph titled Important! : To get a backtrace with correct information you must have PHP configured with --enable-debug! So you want to build PHP, not Apache with debug information. – mctylr Mar 21 '10 at 20:26
make EXTRA_CFLAGS="-g" The EXTRA_CFLAGS is an environment variable, not a command parameter, you want to do EXTRA_CFLAGS="-g" make – mctylr Mar 21 '10 at 20:27

RH packs debug symbols in separate rpm packages.

Try installing these...

share|improve this answer
What are these packages called? – blockhead Mar 19 '10 at 18:34
Actually that won't help me, since I'm compiling from scratch. – blockhead Mar 19 '10 at 18:57

I think the RPMs that contain debugging information are named <pkg>-debuginfo-<...>. You can install them with the debuginfo-install <pkg> command under Fedora 12, which may work under Red Hat systems too.

share|improve this answer

Make sure the debug symbols aren't getting stripped as part of the apache installation process. It's common to run 'strip' on binaries to remove said symbols when they get copied to /usr/local/bin or wherever.

share|improve this answer

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.