From owner-freebsd-hackers Tue Jan 12 14:19:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19535 for freebsd-hackers-outgoing; Tue, 12 Jan 1999 14:19:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA19530 for ; Tue, 12 Jan 1999 14:19:05 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA05830; Tue, 12 Jan 1999 15:18:30 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd005569; Tue Jan 12 15:18:14 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id PAA06290; Tue, 12 Jan 1999 15:18:07 -0700 (MST) From: Terry Lambert Message-Id: <199901122218.PAA06290@usr09.primenet.com> Subject: Re: Problems with 3.0 To: mike@smith.net.au (Mike Smith) Date: Tue, 12 Jan 1999 22:18:07 +0000 (GMT) Cc: rch@iserve.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901120734.XAA01513@dingo.cdrom.com> from "Mike Smith" at Jan 11, 99 11:34:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I have been currently having problems with FreeBSD 3.0-RELEASE, and was > > hoping someone here might have an idea of what is causing this. Here's what > > is happening. > > > > /kernel: pid 22761 (httpd), uid 65534: exited on signal 11 > > > > This error will repeat itself over and over, untill I stop the process, and > > restart it. I'm not sure if it's a problem with apache though, as it has > > happened to inetd, and cron as well. At first I thought maybe it was a > > problem with the ram, so I've replaced that twice, still no luck. I'm > > getting ready to swap the CPU as well. Any ideas would be appeciated. > > The fact that the error repeats indicates that the cached copy of the > program's text has been corrupted. This typically requires bad RAM, > CPU or motherboard. Are you overclocking? Actually, no. All it requires is the VM system reclaiming a clean page from an in core object without telling the object about it. This can't happen for most things, but mmap seems immune from correct functioning in a lot of ways, and this happens to be one of them. The pages that get zapped are in the libc code section for the mmap'ed libc.so image. This probably has something to do with the fact that the same libc is mapped into multiple processes (e.g., here's some place where having aliases in your VM sucks out). Another one recently discovered is that it *appears* that you can map (read only) the same file twice letting the system decide where to put it (pass NULL as binding location), and the second time the system will return the same address as the first time, instead of doing the right thing and setting up the mapping at a different location. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message