It seems the call to "register_cleanup" (#defined to ap_register_cleanup) within php_create_dir in mod_php4.c(line 566) isn't happening properly, as though mod_php4 has forgotten the location of the register_cleanup function.

If I put printf's in php_create_dir surrounding the call to register_cleanup, I see the output up to the point where register_cleanup is called, but not after. The segfault is definitely happening when register_cleanup is called.

In addition, if I put printf's in Apache's ap_register_cleanup function and rebuild it, I see the output when each DSO loads, except php-- it segfaults first.

Also, in Apache's ap_register_cleanup() (alloc.c), I inserted this line to look at the location of the function:

printf("In ap_register_cleanup: %d\n", &ap_register_cleanup);

Then in php's php_create_dir() (mod_php4.c), I inserted a similar line right before the call to register_cleanup to see what _it_ thought the location of the function was:

printf("register_cleanup: %d\n", &register_cleanup);

Here's the output I get:

# httpd -X
In ap_register_cleanup: 536938472
In ap_register_cleanup: 536938472
In ap_register_cleanup: 536938472
...
In ap_register_cleanup: 536938472
In php_create_dir
After per_dir_info
After zend_hash_init
register_cleanup: 934628
Segmentation fault(coredump)


Here's the relevant output from 'dump -Tv libphp4.so'; I'm not sure whether it will mean anything.

libphp4.so:

***Loader Section***

***Loader Symbol Table Information***

[Index] Value      Scn   IMEX Sclass Type   IMPid    Name
...
1429    0x00000000 undef IMP  DS     EXTref [noIMid] ap_register_cleanup
...

If there's any other information that would be helpful, please don't hesitate to ask.

Again, I don't know whether this will be useful, but it's more information. :)

$ nm libphp4.so | grep register_cleanup

.ap_register_cleanup T  269226332
.ap_register_cleanup t  269226332  40
ap_register_cleanup  U          -
ap_register_cleanup  d  537103200   4

Does this problem still persist with more recent version of php (from CVS or http://snaps.php.net) ??

--Jani

Yes, as of php4-200008220745 the problem still exists. I've changed the following:

PHP 4-200008220745
IBM C for AIX (vac.C 5.0.1.0)

$ export CC="cc_r"
$ export CFLAGS=""
$ export LDFLAGS=""
$ ./configure --enable-c9x-inline \
--enable-trans-sid \
--prefix=/local/php \
--with-apxs=/local/www/bin/apxs \
--with-config-file-path=/local/php/etc \
--without-mysql \
--with-regex=apache \
--enable-sigchild

Changed status back to open.

Have you tried using gcc ??

--Jani

No, this bug is concerned specifically with use of the IBM compiler.

Here are the results from the latest version. The following have changed:

PHP 4-200008230945

export CFLAGS="-g -ma"

./configure --enable-c9x-inline \
--enable-debug \
--prefix=/local/www/php \
--with-apxs=/local/www/bin/apxs \
--with-config-file-path=/local/www/php/etc \
--without-mysql

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 "http_config.c"
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
Continuing.

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/libphp4.so")
    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 ()

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 libphp4.so 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
libphp4.so 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 libphp4.so, 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 lines:

# 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 \${wl}-bnoentry\${allow_undefined_flag}"
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 \${wl}-bnoentry\${allow_undefined_flag}"

The bit I added (in both lines) is:
\${wl}-bI:/usr/local/apache/libexec/httpd.exp

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.

Could you try the latest snapshot from http://snaps.php.net/
to see if this is fixed now?

--Jani

The segfault still occurs as of php4-200102131445.

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?

Still happening as of 4.0.5.

Marked as to be fixed before 4.0.6

--Jani

I've committed a fix to CVS. Please give it a try and let us know whether it works for you.

I've tried compiling with the latest CVS. This is my environment:

AIX 4.3.3
IBM VisualAge C 5.0.1.3

export CC="cc_r"
export CFLAGS="-g -ma"
export LDFLAGS=""

configure --enable-c9x-inline \
--prefix=/local/www/php \
--with-apxs=/local/www/bin/apxs \
--with-config-file-path=/local/www/php \
--without-mysql


Here are the results:

$ make
...
Making all in .
        /bin/sh /home/dshafer/src/php/php4/libtool --silent --mode=link cc_r  -I. -I/home/dshafer/src/php/php4/ -I/home/dshafer/src/php/php4/main -I/home/dshafer/src/php/php4 -I/local/www/include -I/home/dshafer/src/php/php4/Zend -I/home/dshafer/src/php/php4/ext/xml/expat -I/home/dshafer/src/php/php4/TSRM  -DAIX=43 -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT -DXML_BYTE_ORDER=21 -g -ma -prefer-pic   -o libphp4.la -rpath /home/dshafer/src/php/php4/libs -avoid-version   stub.lo  Zend/libZend.la  sapi/apache/libsapi.la  main/libmain.la  regex/libregex.la  ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la ext/xml/libxml.la  TSRM/libtsrm.la -ldl -lcrypt -lbind -lm -ldl
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_language_parser.lo contains an incorrect file suffix
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_ini_parser.lo contains an incorrect file suffix
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_alloc.lo contains an incorrect file suffix
...
cc_r: 1501-218 file TSRM/.libs/libtsrm.al contains an incorrect file suffix
ld: 0711-317 ERROR: Undefined symbol: ap_block_alarms
ld: 0711-317 ERROR: Undefined symbol: ap_unblock_alarms
ld: 0711-317 ERROR: Undefined symbol: .ap_register_cleanup
ld: 0711-317 ERROR: Undefined symbol: .ap_pstrdup
ld: 0711-317 ERROR: Undefined symbol: .ap_table_get
ld: 0711-317 ERROR: Undefined symbol: .ap_getword
ld: 0711-317 ERROR: Undefined symbol: .ap_uudecode
ld: 0711-317 ERROR: Undefined symbol: .ap_getword_nulls_nc
ld: 0711-317 ERROR: Undefined symbol: .ap_block_alarms
ld: 0711-317 ERROR: Undefined symbol: .ap_unblock_alarms
ld: 0711-317 ERROR: Undefined symbol: .ap_log_error
ld: 0711-317 ERROR: Undefined symbol: ap_user_name
ld: 0711-317 ERROR: Undefined symbol: ap_user_id
ld: 0711-317 ERROR: Undefined symbol: ap_group_id
ld: 0711-317 ERROR: Undefined symbol: ap_max_requests_per_child
ld: 0711-317 ERROR: Undefined symbol: ap_server_root
ld: 0711-317 ERROR: Undefined symbol: top_module
ld: 0711-317 ERROR: Undefined symbol: .ap_child_terminate
ld: 0711-317 ERROR: Undefined symbol: .ap_sub_req_lookup_uri
ld: 0711-317 ERROR: Undefined symbol: .ap_destroy_sub_req
ld: 0711-317 ERROR: Undefined symbol: .ap_table_set
ld: 0711-317 ERROR: Undefined symbol: .ap_run_sub_req
ld: 0711-317 ERROR: Undefined symbol: .ap_rflush
ld: 0711-317 ERROR: Undefined symbol: .ap_rwrite
ld: 0711-317 ERROR: Undefined symbol: .ap_add_version_component
ld: 0711-317 ERROR: Undefined symbol: .ap_setup_client_block
ld: 0711-317 ERROR: Undefined symbol: .ap_update_mtime
ld: 0711-317 ERROR: Undefined symbol: .ap_set_last_modified
ld: 0711-317 ERROR: Undefined symbol: .ap_set_etag
ld: 0711-317 ERROR: Undefined symbol: .ap_hard_timeout
ld: 0711-317 ERROR: Undefined symbol: .ap_add_common_vars
ld: 0711-317 ERROR: Undefined symbol: .ap_add_cgi_vars
ld: 0711-317 ERROR: Undefined symbol: .ap_kill_timeout
ld: 0711-317 ERROR: Undefined symbol: .ap_send_http_header
ld: 0711-317 ERROR: Undefined symbol: .ap_table_add
ld: 0711-317 ERROR: Undefined symbol: .ap_signal
ld: 0711-317 ERROR: Undefined symbol: .ap_get_client_block
ld: 0711-317 ERROR: Undefined symbol: .ap_reset_timeout
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make: 1254-004 The error code from the last command is 8.

Stop.
make: 1254-004 The error code from the last command is 1.

Stop.

This should be fixed with PHP 4.0.6, please try the 
latest release candidate:

http://www.php.net/~andi/php-4.0.6RC2.tar.gz

-Jani

I tried compiling php-4.0.6RC2, but I seem to be getting the old results again. Interestingly, I no longer see mention of "httpd.exp" (as opposed to php4-200105210845, which had addressed that problem), so apparently we're back to the original behavior-- it compiles, but I get the same segfault. Were the earlier changes (see 2001-05-18) backed out for some reason?

$ grep -l "httpd.exp" php-4.0.6RC2/*

$ grep -l "httpd.exp" php4-200105210845/*
php4-200105210845/config.log
php4-200105210845/configure


Here's my compilation process-- I don't think anything has changed:

export CC="cc_r"
export CFLAGS="-g -ma"
export LDFLAGS=""

./configure	--enable-c9x-inline \
		--prefix=/local/www/php \
		--with-apxs=/local/www/bin/apxs \
		--with-config-file-path=/local/www/php \
		--without-mysql
...

$ make
...
        /bin/sh /local/php/src/php-4.0.6RC2/libtool --silent --mode=link cc_r  -I. -I/local/php/src/php-4.0.6RC2/ -I/local/php/src/php-4.0.6RC2/main -I/local/php/src/php-4.0.6RC2 -I/local/www/include -I/local/php/src/php-4.0.6RC2/Zend -I/local/php/src/php-4.0.6RC2/ext/xml/expat/xmltok -I/local/php/src/php-4.0.6RC2/ext/xml/expat/xmlparse -I/local/php/src/php-4.0.6RC2/TSRM  -DAIX=43 -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -ma   -o libphp4.la -rpath /local/php/src/php-4.0.6RC2/libs -avoid-version   stub.lo  Zend/libZend.la  sapi/apache/libsapi.la  main/libmain.la  regex/libregex.la  ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la ext/xml/libxml.la  TSRM/libtsrm.la -ldl -lcrypt -lbind -lm -ldl
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_language_parser.lo contains an incorrect file suffix
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_ini_parser.lo contains an incorrect file suffix
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_alloc.lo contains an incorrect file suffix
...
cc_r: 1501-218 file .libs/libphp4.lax/libtsrm.al/tsrm_virtual_cwd.lo contains an incorrect file suffix
Target "all-p" is up to date.
Making all in pear
Target "all" is up to date.
Target "all" is up to date.

$ su

# /usr/sbin/slibclean # force unload of dynamic libs with usage count of 0 on AIX

# make install
...

# /local/www/bin/httpd -X
Segmentation fault(coredump)

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

Segmentation fault in php_save_umask at line 117 in file "" ($t1)
could not read "mod_php4.c"
(dbx) where
php_save_umask(), line 117 in "mod_php4.c"
php_create_dir(p = 0x2001ef28, dummy = (nil)), line 601 in "mod_php4.c"
ap_single_module_configure(0x2001ef28, 0x2001ef50, 0x200897a0), line 1500 in "http_config.c"
load_module(0x2ff22938, 0x0, 0x2001f748, 0x2001f758), line 282 in "mod_so.c"
invoke_cmd(0x2000f5e0, 0x2ff22938, 0x0, 0x2ff20910), line 818 in "http_config.c"
unnamed block $b14, line 1008 in "http_config.c"
ap_handle_command(0x2ff22938, 0x2001f480, 0x2ff208e0), line 1008 in "http_config.c"
unnamed block $b16, line 1022 in "http_config.c"
ap_srm_command_loop(0x2ff22938, 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 = 0x2ff22b30), line 4955 in "http_main.c"
(dbx) quit

# 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) r
Starting program: /local/www/bin/httpd 
"/usr/lib/libpthreads.a": not in executable format: File format not recognized.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xd0aec98c in __dbsubn ()
(gdb) where
#0  0xd0aec98c in __dbsubn ()
#1  0xd0aeaf38 in __dbsubn ()
#2  0x10034108 in ap_single_module_configure (p=0x2001ef28, s=0x2001ef50, 
    m=0x200897a0) at http_config.c:1500
#3  0x10068760 in load_module (cmd=0x2ff22918, dummy=0x0, 
    modname=0x2001f748 "php4_module", filename=0x2001f758 "libexec/libphp4.so")
    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=1, argv=0x2ff22b0c) at http_main.c:4955
#10 0x100001dc in __start ()
(gdb) 

According to Sascha, the fixes were not put into
the 4.0.6 branch, they are only in the HEAD branch
of the CVS. Could you please check it out? And let
us know if this really is fixed or not.

--Jani

Do you try it with the HEAD branch (From CVS) already?

I just tried the latest code from CVS on 2001-07-11, and the problem appears to be fixed now. Thanks!

Closed. Finally.. :)
Reopen if this problem raises it's ugly head again.

--Jani