Bug #4630 Updated: Segmentation fault(coredump) in apache startup

ID: 4630 Updated by: sniper Reported By: david-shafer@uiowa.edu 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] david-shafer@uiowa.edu Still happening as of 4.0.5. --------------------------------------------------------------------------- [2001-04-26 17:05:24] dshafer@php.net 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] david-shafer@uiowa.edu The segfault still occurs as of php4-200102131445. --------------------------------------------------------------------------- [2000-12-18 10:55:46] sniper@php.net 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] david-shafer@uiowa.edu 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=4630&edit=2