php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15774 apache dies immediately after starting
Submitted: 2002-02-28 02:21 UTC Modified: 2002-02-28 13:21 UTC
From: micah at colltech dot com Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 4.1.2 OS: GNU/Linux Debian Potato
Private report: No CVE-ID: None
 [2002-02-28 02:21 UTC] micah at colltech dot com
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...


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-28 02:24 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.
 [2002-02-28 02:43 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
 [2002-02-28 02:50 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).
 [2002-02-28 02:52 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.
 [2002-02-28 03:12 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.



 [2002-02-28 04:35 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?
 [2002-02-28 05:47 UTC] yohgaki@php.net
I hope apache detects the misconfiguration and print nice error, too :)
 [2002-02-28 13:21 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)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 16:01:29 2024 UTC