The most up-to-date resource for bug tracking and information is the Apache bug database. Significant bugs at release time will also be noted there. If you are running a 1.2 beta release or version 1.1.3 or earlier and thing you have found a bug, please upgrade to 1.2. Many bugs in early versions have been fixed in 1.2.
See Also: Compatibility notes
cd to your apache_1.2.1 directory, and type patch
-s -p1 . Then rebuild Apache.-DNO_SLACK to EXTRA_CFLAGS in your Configuration
file, re-run Configure and rebuild your server. This disables the descriptor slack workaroundThis problem will be tracked as PR#832.
NO_SLACK or patch
provided by the previous bug are applied.) Solaris 2.5.1 (and probably other versions of
Solaris) appear to have a race condition completely unrelated to all the others. It is
possible during a SIGHUP that the server will fail to start because it will not be able to
re-open its sockets. To our knowledge this has only shown up during testing when we pummel
the server with as many SIGHUP requests per second as we can. This appears unrelated to
the similar sounding bug described in PR#832.
-DUSE_FLOCK_SERIALIZED_ACCEPT
to the EXTRA_CFLAGS line in your Configuration and rebuild. (If you encounter
problems with that, you can also try -DUSE_FCNTL_SERIALIZED_ACCEPT.) This
affects any architecture that doesn't use one of the USE_xxxxx_SERIALIZED_ACCEPT
definitions, see the source file conf.h for your architecture. This will be
tracked as PR#467. %2f. This
will be tracked as PR#543. SunOS4 has a kernel bug in the allocation of memory for the mbuf table. When it fills up, the result is a Panic the next time any routine tries to set something in an imaginary mbuf beyond the range of the table. Due to buggy browser behavior and the lack of a FIN_WAIT_2 timeout on SunOS4, "KeepAlive Off" is necessary to avoid filling up the mbuf table on busy sites.
gcc:
noinline: No such file or directory". Fix is given in PR#695. -lbind to EXTRA_LDFLAGS in Configuration.
See PR#616 and the Apache FAQ. created shared memory segment #730499" in error_log
is not an error and should be ignored. See PR#696. "mod_include.c",
line 1123: warning: end-of-loop code not reached. This is a bogus warning and can
be ignored. See PR#681. ![]()