| Bug #15774 | apache dies immediately after starting | ||||
|---|---|---|---|---|---|
| Submitted: | 28 Feb 2002 2:21am UTC | Modified: | 28 Feb 2002 1:21pm UTC | ||
| From: | micah at colltech dot com | Assigned to: | |||
| Status: | Bogus | Category: | Reproducible crash | ||
| Version: | 4.1.2 | OS: | GNU/Linux Debian Potato | ||
[28 Feb 2002 2:24am UTC] rasmus@php.net
There is nothing here to go on. If you could compile and run 4.1.1 you can compile and run 4.1.2. Nothing was changed that would cause this sort of problem. Your strace doesn't even touch anything in PHP. Check your build options for 4.1.1, compare them to what you are doing for 4.1.2. I suspect user-error here.
[28 Feb 2002 2:43am UTC] micah at colltech dot com
This is what I am using for my apache configuration: ./configure \ --prefix=/usr/local/apache \ --enable-module=unique_id \ --enable-module=rewrite \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=so \ --logfiledir=/var/log/apache \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=vhost_alias This is what I am using for my php configuration: ./configure \ --prefix=/usr/local/php \ --with-apache=../apache_1.3.23 \ --enable-ftp \ --with-xml \ --enable-track-vars \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql/ \ --enable-debug \--with-config-file-path=/usr/local/php/lib also, ran gdb and did a little poking around: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit
[28 Feb 2002 2:50am UTC] micah at colltech dot com
Actually, I was running 4.0.6 before this upgrade, not 4.1.1, but I did use the same configuration options that I used from 4.0.6 (I always save my ./configure options so that I can recreate them).
[28 Feb 2002 2:52am UTC] micah at colltech dot com
Did some more poking in gdb: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit Not a very useful error... if this is user error, it isn't very obvious what is wrong.
[28 Feb 2002 3:12am UTC] yohgaki@php.net
Reopened. You have something wrong. Exit code 0377 is actually a 255(or -1). Apache is exiting without proper exit code set, most likely. I suggest to get rid of module one by one and locate which module is offending module and let us know.
[28 Feb 2002 4:35am UTC] joey@php.net
After working with user on IRC for a while, the problem appears to have been loading a dynamic PHP module in an apache that had a later PHP version builtin. Perhaps there is some way we could watch for this and let the user know what they've dong?
[28 Feb 2002 5:47am UTC] yohgaki@php.net
I hope apache detects the misconfiguration and print nice error, too :)
[28 Feb 2002 1:21pm UTC] micah at colltech dot com
The configuration problem was in the apache configuration, however it was on the PHP side. I was compiling in the php module static, yet also trying to load the module. A simple check at the first load of PHP as a dynamic module to see if php support is already built into apache would do the trick. Apache has no mechanism to tell if a module is loaded or not, perhaps it ought to have better hooks for this sort of thing, but until then maybe PHP should shine and do this check itself. This is the second time I've been caught in the middle of a PHP/Apache finger pointing. Apache says it is PHP's poor error reporting, PHP says it is Apache's fault. Meanwhile, I spend literally hours (unplanned in this case due to the security bug) trying to get php/apache to work on the 4th system that day. I like PHP and I like Apache, and I accept having to update all my systems that run them when it is needed, but nobody should do what I had to do. :) Just a little bit of coordination between the two projects could really iron out a lot of problems and instead of an obscure lookng zend related problem, I could get hit with a cluestick, "You are trying to load a module that is compiled in statically, duuuh" btw. I will be submitting this to apache as well, and I dont want to hear from both sides that the other should do it, that would be really frustrating (admitedly, it wouldn't turn me to Microsoft, but it would be disheartening to see two great projects acting this way)
This is actually php version 4.1.2 (there is no selection for that in this form). I've compiled a new version of apache 1.2.23 and PHP 4.1.2 and when I try to start apache it dies immediately without any errors in the error_log or anywhere else. I tried to strace the binary, but nothing showed up, with --enable-debug on, I get the following: zend_hash.c(532) : ht=0x081d8860 is already destroyed zend_hash.c(98) : Bailed out without a bailout address! in my error log. If I try to do a gdb back trace I get the following: (gdb) run -X Starting program: /usr/local/apache/bin/httpd_new -X Program exited with code 0377. (gdb) bt No stack. When I didn't have --enable-debug compiled in and I attempted to do a backtrace, I got the following: F10 key ==> File Edit Search Buffers Windows System Help Program received signal SIGSEGV, Segmentation fault. 0x28893e in malloc () from /lib/libc.so.6 crap, hold on exited gdb already :) I dont like having our webserver down for so long ok did the bt #0 0x28893e in malloc () from /lib/libc.so.6 #1 0x28987d in calloc () from /lib/libc.so.6 #2 0x11888e in _dl_new_object () from /lib/ld-linux.so.2 #3 0x1152e4 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 #4 0x116d7b in _dl_map_object () from /lib/ld-linux.so.2 #5 0x1196ac in _dl_map_object_deps () from /lib/ld-linux.so.2 #6 0x2ff6e3 in getutmpx () from /lib/libc.so.6 #7 0x11a365 in _dl_catch_error () from /lib/ld-linux.so.2 #8 0x2ff900 in _dl_open () from /lib/libc.so.6 #9 0x13135e in _pam_token_returns () from /lib/libdl.so.2 #10 0x11a365 in _dl_catch_error () from /lib/ld-linux.so.2 #11 0x13194e in dlerror () from /lib/libdl.so.2 #12 0x13139b in dlopen () from /lib/libdl.so.2 #13 0x8148c67 in ap_os_dso_load () #14 0x8085f58 in load_module () #15 0x812b69e in invoke_cmd () #16 0x812c001 in ap_handle_command () #17 0x812c09d in ap_srm_command_loop () #18 0x812c769 in ap_process_resource_config () #19 0x812d0b0 in ap_read_config () #20 0x81378f3 in standalone_main () #21 0x813826c in main () #22 0x251a42 in __libc_start_main () from /lib/libc.so.6 Until I can get this working, I am running with the remote root exploit! Please help, thanks...