ID: 4630
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Description: Segmentation fault(coredump) in apache startup

Still happening as of 4.0.5.

Previous Comments:

[2001-04-26 17:05:24] [EMAIL PROTECTED]
Still happening as of 4.0.4pl1. It seems like there's enough information to fix the 
problem, for somebody who knows the source code. Would someone be able to look at 
this? Is there any more information you need?


[2001-02-15 15:10:36] [EMAIL PROTECTED]
The segfault still occurs as of php4-200102131445.


[2000-12-18 10:55:46] [EMAIL PROTECTED]
Could you try the latest snapshot from
to see if this is fixed now?



[2000-09-08 19:42:47] [EMAIL PROTECTED]
After forwarding the issue to a compiler expert at IBM, I received the fix below, 
which I've tested and confirmed. Does anyone know how best to implement this fix?

The point where you found the segment fault was when php_create_dir attempted to call 
ap_register_cleanup. As it happens, php_create_dir is in and 
ap_register_cleanup is in httpd. In order to make this work on AIX, httpd has to be 
bound with an export list and has to be bound with an import list.

Fortunately, the Apache part is already set up correctly.  When you install apache on 
AIX, $PREFIX/libexec/httpd.exp is a correctly formatted import/export file.

The PHP4 part, however was not set up correctly. In fact it was set up in the worst 
possible way under the circumstances. If you were to attempt to naively bind, the linker would produce a fatal error because ap_register_cleanup is 
undefined. $PHP4/libtool (which
I believe is generated by configure) gets around this inconvenience by adding a 
-berrok linker option. (It's called ${allow_undefined_flag}) So, the linker on AIX 
basically leaves the reference to ap_register_cleanup untouched so the call branches 
to a pseudo-random piece of code. After that, bad things happen.

I'm running now because I manually changed $PHP4/libtool so that it contains these 

# Commands used to build and install a shared archive.
archive_cmds="$CC ${wl}-bM:SRE -o $objdir/$soname $libobjs $deplibs $linkopts 
${wl}-bexpall ${wl}-bI:/usr/local/apache/libexec/httpd.exp 
archive_expsym_cmds="$CC ${wl}-bM:SRE -o $objdir/$soname $libobjs $deplibs $linkopts 
${wl}-bI:/usr/local/apache/libexec/httpd.exp ${wl}-bE:$export_symbols 

The bit I added (in both lines) is:

I have no idea what the ${wl} is; I just copied the existing pattern. I hard coded 
/usr/local/apache/libexec/httpd.exp. Obviously, the real export file should be 
identifed using something like apxs, but I don't know how to do that.

At any rate, httpd has now been running for a while on my machine.


[2000-08-24 00:02:42] [EMAIL PROTECTED]
Here are the results from the latest version. The following have changed:

PHP 4-200008230945

export CFLAGS="-g -ma"

./configure --enable-c9x-inline 

bud # ./httpd -X
Segmentation fault(coredump)

bud # dbx httpd
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in php_save_umask at line 121 in file "" ($t1)
could not read "mod_php4.c"
(dbx) where       
php_save_umask(), line 121 in "mod_php4.c"
php_create_dir(p = 0x2001ef28, dummy = (nil)), line 556 in "mod_php4.c"
ap_single_module_configure(0x2001ef28, 0x2001ef50, 0x200b9db8), line 1500 in 
load_module(0x2ff22948, 0x0, 0x200432d0, 0x200432e0), line 282 in "mod_so.c"
invoke_cmd(0x2000f5e0, 0x2ff22948, 0x0, 0x2ff20920), line 818 in "http_config.c"
unnamed block $b14, line 1008 in "http_config.c"
ap_handle_command(0x2ff22948, 0x2001f480, 0x2ff208f0), line 1008 in "http_config.c"
unnamed block $b16, line 1022 in "http_config.c"
ap_srm_command_loop(0x2ff22948, 0x2001f480), line 1022 in "http_config.c"
ap_process_resource_config(0x2001ef50, 0x2001f608, 0x2001ef28, 0x20022f68), line 1202 
in "http_config.c"
ap_read_config(0x2001ef28, 0x20022f68, 0x200052a0), line 1481 in "http_config.c"
http_main.main(argc = 2, argv = 0x2ff22b3c), line 4955 in "http_main.c"
(dbx) quit

bud # gdb httpd
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.14 (rs6000-ibm-aix3.2.5), Copyright 1995 Free Software Foundation, Inc...
(gdb) run -X
Starting program: /local/www/bin/httpd -X
"/usr/lib/libpthreads.a": not in executable format: File format not recognized.
(gdb) continue

Program received signal SIGSEGV, Segmentation fault.
0xd176376c in __dbsubn ()
(gdb) bt
#0  0xd176376c in __dbsubn ()
#1  0xd1761e44 in __dbsubn ()
#2  0x10034108 in ap_single_module_configure (p=0x2001ef28, s=0x2001ef50, 
    m=0x200b9db8) at http_config.c:1500
#3  0x10068760 in load_module (cmd=0x2ff22918, dummy=0x0, 
    modname=0x200432d0 "php4_module", filename=0x200432e0 "libexec/")
    at mod_so.c:282
#4  0x100311c0 in invoke_cmd (cmd=0x2000f5e0, parms=0x2ff22918, mconfig=0x0, 
    args=0x2ff208f0) at http_config.c:818
#5  0x10032568 in ap_handle_command (parms=0x2ff22918, config=0x2001f480, 
    l=0x2ff208c0) at http_config.c:1008
#6  0x100341ac in ap_srm_command_loop (parms=0x2ff22918, config=0x2001f480)
    at http_config.c:1022
#7  0x100330ec in ap_process_resource_config (s=0x2001ef50, 
    fname=0x2001f608 "/local/www/conf/httpd.conf", p=0x2001ef28, 
    ptemp=0x20022f68) at http_config.c:1202
#8  0x10033fe4 in ap_read_config (p=0x2001ef28, ptemp=0x20022f68, 
    confname=0x200052a0 "conf/httpd.conf") at http_config.c:1481
#9  0x100007f4 in main (argc=2, argv=0x2ff22b14) at http_main.c:4955
#10 0x100001dc in __start ()


The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at:

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to