[PHP-DEV] Bug #4630 Updated: Segmentation fault(coredump) in apache startup
ID: 4630 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Status: Closed Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.0.6RC2 New Comment: Closed. Finally.. :) Reopen if this problem raises it's ugly head again. --Jani Previous Comments: [2001-07-11 14:05:49] [EMAIL PROTECTED] I just tried the latest code from CVS on 2001-07-11, and the problem appears to be fixed now. Thanks! [2001-07-03 04:48:34] [EMAIL PROTECTED] Do you try it with the HEAD branch (From CVS) already? [2001-06-12 19:00:30] [EMAIL PROTECTED] 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 [2001-06-04 19:26:50] [EMAIL PROTECTED] 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
[PHP-DEV] Bug #4630 Updated: Segmentation fault(coredump) in apache startup
ID: 4630 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.0.6RC2 New Comment: I just tried the latest code from CVS on 2001-07-11, and the problem appears to be fixed now. Thanks! Previous Comments: [2001-07-03 04:48:34] [EMAIL PROTECTED] Do you try it with the HEAD branch (From CVS) already? [2001-06-12 19:00:30] [EMAIL PROTECTED] 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 [2001-06-04 19:26:50] [EMAIL PROTECTED] 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
[PHP-DEV] Bug #4630 Updated: Segmentation fault(coredump) in apache startup
ID: 4630 Updated by: derick Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating system: PHP Version: 4.0.6RC2 Assigned To: Comments: Do you try it with the HEAD branch (From CVS) already? Previous Comments: --- [2001-06-12 19:00:30] [EMAIL PROTECTED] 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 --- [2001-06-04 19:26:50] [EMAIL PROTECTED] 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,
[PHP-DEV] Bug #4630 Updated: Segmentation fault(coredump) in apache startup
ID: 4630 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Compile Failure Operating system: PHP Version: 4.0.6RC2 Assigned To: Comments: 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 Previous Comments: --- [2001-06-04 19:26:50] [EMAIL PROTECTED] 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,
[PHP-DEV] Bug #4630 Updated: Segmentation fault(coredump) in apache startup
ID: 4630 Updated by: sas Reported By: [EMAIL PROTECTED] Old-Status: Critical Status: Feedback Bug Type: Compile Failure Operating system: PHP Version: 4.0.5 Assigned To: Comments: I've committed a fix to CVS. Please give it a try and let us know whether it works for you. Previous Comments: --- [2001-05-09 11:21:57] [EMAIL PROTECTED] Marked as to be fixed before 4.0.6 --Jani --- [2001-05-03 15:01:26] [EMAIL PROTECTED] Still happening as of 4.0.5. --- [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 http://snaps.php.net/ to see if this is fixed now? --Jani --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=4630edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #4630 Updated: Segmentation fault(coredump) in apache startup
ID: 4630
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Critical
Bug Type: Compile Failure
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Marked as to be fixed before 4.0.6
--Jani
Previous Comments:
---
[2001-05-03 15:01:26] [EMAIL PROTECTED]
Still happening as of 4.0.5.
---
[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 http://snaps.php.net/
to see if this is fixed now?
--Jani
---
[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 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.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=4630edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #4630 Updated: Segmentation fault(coredump) in apache startup
ID: 4630
Updated by: dshafer
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
PHP Version: 4.0.4pl1
Assigned To:
Comments:
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?
Previous Comments:
---
[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 http://snaps.php.net/
to see if this is fixed now?
--Jani
---
[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 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.
---
[2000-08-24 00:02:42] [EMAIL PROTECTED]
Here are the results from the latest version. The following have changed:
PHP 4-28230945
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)
