You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1998/01/21 23:46:17 UTC
yet another project: arch specific docs
Here's a documentation project for whomever wants it. We've got notes on
running apache on various architectures, some of which are out of date.
Some of which haven't ever been put in the docs. It would be rad if all
those docs were moved to a common location, say
htdocs/manual/arch/archname.html.
Here's a few messages from my hugely long "todo" list which could go in
there.
There's also an OSF/1 bug report against 1.3a1 or so, because we
completely melt SMP alpha boxes unless a certain patch is applied. See
the bugdb for details.
Even if the docs amount to a bunch of notes like "here's a bunch of
messages, we're providing them unedited because we feel that providing
something is better than providing nothing".
Dean
---------- Forwarded message ----------
X-bandwidth-by: Hyperreal
Date: Mon, 22 Sep 1997 13:16:04 -0700 (PDT)
From: Dean Gaudet <dg...@arctic.org>
To: new-httpd@apache.org
Subject: Re: SunOS4.1.X sockopt panic (fwd)
Reply-To: new-httpd@apache.org
We've had this reported as a bug in apache too ... I forget what we always
suggested as the workaround.
Dean
---------- Forwarded message ----------
Date: Mon, 22 Sep 1997 15:12:42 -0400
From: HAKNER JEFF <ha...@COOPER.EDU>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: SunOS4.1.X sockopt panic
>>1992 or 1993, with exploit (commonly called "boom.c"). Forgive me,
>>but did Sun ever release a patch for this bug? It appears to be extant
>>on 4.1.3U1 with all current patches applied.
>
>
>well, not all current patches have been applied then.
>
>Patch id (for 4.1.3_U1) is:
>
>102010-05: SunOS 4.1.3_U1: TCP Interface Patch
>
>Casper
OK, thanks for the info. Oddly, this isn't on the list of "Recommended"
patches, nor is it available without a support contract.
---------- Forwarded message ----------
X-bandwidth-by: Hyperreal
Date: Tue, 23 Sep 1997 21:52:56 -0600 (MDT)
From: Marc Slemko <ma...@worldgate.com>
To: Apache - BYOC <ne...@apache.org>
Subject: Memory leak in accept(), Solaris 2.5.1 (fwd)
Reply-To: new-httpd@apache.org
Interesting. If true, another reason to use serialized accepts.
---------- Forwarded message ----------
>Path: scanner.worldgate.com!news.insinc.net!newsfeed.direct.ca!newsfeed.internetmci.com!206.28.166.253!news.probe.net!not-for-mail
>From: mgleFIXTHISason@probe.net (Mike Gleason, remove the FIXTHIS)
>Newsgroups: comp.unix.solaris
>Subject: Memory leak in accept(), Solaris 2.5.1
>Date: Wed, 24 Sep 1997 02:49:02 GMT
>Organization: NCEMRSoft
>Lines: 157
>Message-ID: <34...@news.probe.net>
>NNTP-Posting-Host: max2-16.probe.net
>X-Newsreader: Forte Free Agent 1.11/32.235
>Xref: scanner.worldgate.com comp.unix.solaris:117796
I have found a memory leak that affects Solaris 2.5.1 (Intel and
Sparc, with the Sept 17 recommended patch cluster applied) when the
accept() socket library function is used. Memory is leaked when an
alarm causes accept() to jump out of the function, without free()ing
memory malloc()'d by accept().
Perhaps someone could point me to an official method of reporting
this. I'm not a contract customer and I couldn't find anything on the
Sun webs.
Example code (stripped bare for brevity) is next, followed by output
showing how the leak occurs. Unfortunately for TCP/IP servers, this
can cause a long-running daemon process to consume all swap space and
grind the machine to a halt.
---snip---
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <signal.h>
#include <setjmp.h>
char mallbuf[1024 * 100];
char *mbptr;
jmp_buf jmp;
void *
malloc(size_t n)
{
static int calls = 0;
char *p;
char m[64];
if (calls++ == 0) {
mbptr = mallbuf;
}
p = mbptr;
if ((n % 8) == 0)
mbptr += n;
else
mbptr += n + (8 - (n % 8));
write(1, "used malloc\n", 12);
return (p);
} /* malloc */
void
free(void *p)
{
write(1, "used free \n", 12);
} /* free */
static void
hdlr(int num)
{
longjmp(jmp, 1);
} /* hdlr */
main(int argc, char **argv)
{
int s, s2, addrsize;
struct sockaddr_in addr;
unsigned short port;
if (argc < 2) exit(2);
port = (unsigned short) atoi(argv[1]);
write(1, "socket\n", 7);
s = socket(AF_INET, SOCK_STREAM, 0);
(void) memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_port = htons(port);
write(1, "bind \n", 7);
bind(s, &addr, sizeof(addr));
write(1, "listen\n", 7);
listen(s, 2);
for (;;) {
if (setjmp(jmp) != 0) {
alarm(0);
write (1, "accept timeout\n", 15);
}
signal(SIGALRM, hdlr);
alarm(2);
(void) memset(&addr, 0, sizeof(addr));
addrsize = sizeof(addr);
write(1, "accept\n", 7);
s2 = accept(s, &addr, &addrsize);
alarm(0);
if (s2 >= 0) {
write (1, "accept okay \n", 15);
break;
} else {
write (1, "accept error \n", 15);
}
}
write(1, "done\n", 5);
exit(0);
}
---snip---
Output follows. Note how malloc() isn't called until the second time
accept is used.
21 Avalanche ~/src > a.out 5102
socket
used malloc
[...]
used malloc
used free
bind
listen
accept
accept timeout
accept
used malloc
accept timeout
accept
used malloc
accept timeout
accept
used malloc
^C
Workaround:
=========
select() can be used as a timeout mechanism, instead of using alarm().
Diatribe:
======
I've spent three months trying to track down this bug. I also had to
purchase a separate machine and Solaris license on which to load test
an app on a Solaris platform. Although normally that wouldn't be
necessary, it's still tough for a small, independent developer to
support Sun operating systems. I'd happily take a copy of the Sun C
compiler for Intel in exchange for all the resources I had to exhaust
on this one so I wouldn't have to use gcc atleast.
~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mike Gleason, NCEMRSoft. ~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Please remove the "FIXTHIS" from my email address before replying.)
ObPlug: Try NcFTPd (http://www.probe.net/~mgleason/ncftpd/) instead of wu-ftpd!
---------- Forwarded message ----------
X-bandwidth-by: Hyperreal
Date: Sat, 4 Oct 1997 21:11:31 +0100 (BST)
From: Rob Hartill <ro...@imdb.com>
To: Apache Group <ne...@hyperreal.org>
Subject: -DHIGH_SLACK_LINE=256 and irix 6.2 (fwd)
Reply-To: new-httpd@apache.org
---------- Forwarded message ----------
Date: Tue, 30 Sep 1997 13:26:56 -0500 (CDT)
From: Adam Martin <ad...@primary.net>
To: apache-bugs@apache.org
Subject: -DHIGH_SLACK_LINE=256 and irix 6.2
Hi,
It would seem that the problems described here:
*) Attempt to work around problems with third party libraries that do not
handle high numbered descriptors (examples include bind, and
solaris libc). On all systems apache attempts to keep all permanent
descriptors above 15 (called the low slack line). Solaris users
can also benefit from adding -DHIGH_SLACK_LINE=256 to EXTRA_CFLAGS
which keeps all non-FILE * descriptors above 255. On all systems
this should make supporting large numbers of vhosts with many open
log files more feasible. If this causes trouble please report it,
you can disable this workaround by adding -DNO_SLACK to EXTRA_CFLAGS.
[Dean Gaudet] various PRs
*) Related to the last entry, network sockets are now opened before
log files are opened. The only known case where this can cause
problems is under Solaris with many virtualhosts and many Listen
directives. But using -DHIGH_SLACK_LINE=256 described above will
work around this problem. [Dean Gaudet]
are also subject to IRIX 6.2.
we came accross this when our virtual host # in httpd.conf exceeded 244
(the actual # of aliased IPs on this machine is 260)
when going over this limit odd things like httpd not starting
because it couldn't open the error_log file (apache 1.2.4)
and our cgi's core dumping upon access (apache 1.2.0).
adding -DHIGH_SLACK_LINE=256 in apache 1.2.4 and recompiling seemed
to fix the problem.
Thanks,
Adam Martin
Primary Network System Administrator
adam@primary.net