Date: Wed, 13 Jan 1999 19:07:17 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), rch@iserve.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Problems with 3.0 Message-ID: <199901140307.TAA16614@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
:> > 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).
The only libc interaction with mmap() that I know of occurs
if you ( as programs do ) MAP_PRIVATE mmap libc. The pages
the program modifies to fixup jump vectors become swap-backed,
but the rest of libc remains backed by the libc.so file.
If the shared library is then updated, the modified fixup
pages remain untouched (of course!) while the rest of libc
is changed out from under the running program.
This could certainly cause a seg fault.
It is also possible for the system's program TEXT object for
a program binary to become confused when the binary is
updated while the program is also running. It doesn't always
happen. I'm not sure how it's possible for this to happen
but it does. Usually, updating the program binary a second
time fixes the problem.
If the author updated either libc or httpd while the web
server was running, it could certainly have caused the
segfault later on.
-Matt
: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
I've not seen this either. Do you have an example or PR? I
wrote a quick little test program to map the same file several
times and it seems to map it at different locations as it
should. It was hardly an exhaustive test, though.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901140307.TAA16614>