STATUS revision 1f13e103435b26e5288d7404e9a0a0cf5613521c
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz SchröderAPACHE 2.0 STATUS: -*-text-*-
79bf62fdeb8f4775386201433fe2818358fc1a51Till MossakowskiLast modified at [$Date: 2001/06/04 15:29:53 $]
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski 2.0.17 : rolled April 17, 2001
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski 2.0.16 : rolled April 4, 2001
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski 2.0.15 : rolled March 21, 2001
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0.14 : rolled March 7, 2001
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0a9 : released December 12, 2000
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0a8 : released November 20, 2000
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski 2.0a7 : released October 8, 2000
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0a6 : released August 18, 2000
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0a5 : released August 4, 2000
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0a4 : released June 7, 2000
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0a3 : released April 28, 2000
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski 2.0a2 : released March 31, 2000
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2.0a1 : released March 10, 2000
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz SchröderDAEDALUS 2.0 PROBLEMS:
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski * mod_cgid and suexec have a problem co-existing. suexec sees a null
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski command string sometimes.
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski * core dump from 20010418 running 2_0_16
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski #0 0x2813a3c8 in kill () from /usr/lib/libc.so.4
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski #1 0x2817609e in abort () from /usr/lib/libc.so.4
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski #2 0x8065299 in ap_log_assert (szExp=0x80aaa60 "total_bytes_left > 0 && tmplen > 0", szFile=0x80aa2aa "core.c", nLine=2555)
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #3 0x8075227 in sendfile_it_all (c=0x81470fc, fd=0x814759c, hdtr=0xbfbff670, file_offset=1929216, file_bytes_left=261949,
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder total_bytes_left=261949, flags=0) at core.c:2555
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #4 0x80761e2 in core_output_filter (f=0x814737c, b=0x814764c) at core.c:3172
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #5 0x806d227 in ap_pass_brigade (next=0x814737c, bb=0x81e80fc) at util_filter.c:240
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #6 0x805e696 in check_pipeline_flush (r=0x820803c) at http_request.c:388
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #7 0x805e707 in ap_process_request (r=0x820803c) at http_request.c:432
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #8 0x805a1a9 in ap_process_http_connection (c=0x81470fc) at http_core.c:280
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #9 0x806bc60 in ap_run_process_connection (c=0x81470fc) at connection.c:82
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #10 0x806be84 in ap_process_connection (c=0x81470fc) at connection.c:216
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #11 0x805fbba in child_main (child_num_arg=272) at prefork.c:807
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #12 0x805fd20 in make_child (s=0x80c64fc, slot=272) at prefork.c:880
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #13 0x805ffec in perform_idle_server_maintenance () at prefork.c:1021
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #14 0x80603d1 in ap_mpm_run (_pconf=0x80c600c, plog=0x80f300c, s=0x80c64fc) at prefork.c:1191
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #15 0x80660cd in main (argc=1, argv=0xbfbffadc) at main.c:425
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #16 0x8059bf9 in _start ()
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder The input data (received in one read from TCP layer):
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Via: 1.0 MDRPRXY01, 1.0 NS2
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Connection: Keep-Alive
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Accept: application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg,
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Accept-Language: en-us,tscii;q=0.5
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Referer: http://jakarta.apache.org/log4j/docs/download.html
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Accept-Encoding: gzip, deflate
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder The confusion was because apr_sendfile() returned APR_SUCCESS
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder but zero bytes sent. Presumably the FreeBSD kernel sendfile()
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder did the same thing (not 100% sure).
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder * core dump from 20010521 and 20010529 running 2_0_16 - the "3030" problem
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #0 0x80987e8 in apr_cvt (arg=1.3980432860952889e-76,
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder ndigits=808464432, decpt=0x30303030,
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder sign=0x30303030, eflag=808464432,
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder buf=0x30303030 <Address 0x30303030 out of bounds>) at apr_snprintf.c:177
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder #1 0x30303030 in ?? ()
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Cannot access memory at address 0x30303030.
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder In both coredumps the request is /server-status?auto.
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder It is unclear whether the apr_*printf function was passed bad
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder data or it screwed up on its own. 0x30 is '0'. There is a
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder string of 200-300 '0' characters in the dump, apparently
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder overlaying enough of the stack to cause serious problems :)
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz SchröderRELEASE SHOWSTOPPERS:
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder WARNING: ALWAYS check srclib/apr/STATUS and srclib/apr-util/STATUS
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder * File handle caching in mod_file_cache is broken in the multi
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder threaded MPMs. The original intent of caching file handles
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder was that these handles would ONLY be used in an apr_sendfile()
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder call. With recent optimizations added to core_output_filter
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder to pipeline output byte streams, we actually read bytes from
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder these cached file handles into buffers. The problem is that
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder while it is okay for multiple threads to share a file handle
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder for use on a sendfile call (because the filepointer is not used,
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder in sendfile) it is NOT okay for threads to share a file handle
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder for reads or writes (because the filepointer is used in reads
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder and writes). This may also be broken on a few quirky platforms
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder whose sendfile() actually uses the file pointer. Jeff was looking
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder Potential Solutions:
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 1. We either need to ensure that a cached file handle is only
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder used on a sendfile call (Bill prefers this solution. I think.).
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder 2. Cliff Woolley has some ideas about a custom bucket type
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder that would recognise when an apr_file_t is cached (thus shared
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder across threads) and do the right thing to ensure that the
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder filepointer does not get trashed. The idea here is that the
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder "cacheable" file bucket would never allow its file handle to be
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder read by any method OTHER than sendfile. Attempts to do otherwise
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder would result in the file being re-opened for sync io into the
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder request pool, and the new file handle would get put into a regular
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder file bucket which would then be read. This method thus incorporates
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder the spirit of solution #1 while having a fall-back protection
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder scheme. Note that mod_file_cache can still attempt to
79bf62fdeb8f4775386201433fe2818358fc1a51Till Mossakowski be discriminatory and DECLINE requests that it believes will
ebd2b49c422ae4a74eb9df9740d86bdbecd2a82cLutz Schröder result in an apr_bucket_read() call; this solution just allows
the modules/http/config.m4 file has been renamed to
modules/http/config2.m4 to work around this problem, it should moved
* Root all file systems with <Directory /> for WIN32/OS2/NW permissions
rand.c, at least.)
Problems to fix in the revamp: -k shutdown/restart are broken,
allow for Apache config/build against an already-installed
config.m4 incorporated into ./configure, which means "buildconf"
In the Apache-2.0 repository, this directory had a config.m4
The current porting state is summarized in modules/ssl/README. The next
modules/ssl/README can be ported.
modules/ssl/. Do whatever you think is appropriate to get it
#if 0...endif wrapped to not make trouble for you.
malloc/calloc/frees in the bucket brigade code. Need some
"Apache" layout from config.layout, and each variable settable
* All of our MPMs should use APR for threads/processes. This
* Combine log_child and piped_log_spawn. Clean up http_log.c.
* Win32: Migrate the MPM over to use APR thread/process calls. This
losing error status (i.e. throwing away the error returned by a
* All DBMs suffer from confusion in support/dbmmanage (perl script) since
for predictable mod_auth_db/dbm administration.
* Explore use of a post-config hook for the code in http_main.c which
* (possibly) use UUIDs in mod_unique_id and/or mod_usertrack
* shift stuff to mod_core.h
Using NIS passwd.byname dbm files with AuthDBMUserFile
setlogin() is not called, causing problems with e.g. identd
add allow,deny/deny,allow warning to mod_access
A small addition to rotatelogs.c to improve program functionality.
Feedback/Comment on APACI
Inclusion of RPM spec file in CVS/distributions
No way to change ReadmeName/HeaderName suffixes.
MIME types for MNG and JNG files need adding to mime.types and
the mime.types and magic files
* orig_ct in the byterange/multipart handling may not be
obsolete directives in core.html to the MPM documentation.
* Revise manual/stopping.html and the last part of
manual/misc/perf-tuning.html to take account of the MPMs.