Martijn van Oosterhout <kleptog@xxxxxxxxx> writes:
> Hmm? To upgrade libc.so you merely need to delete the old one and
> install the new one, there's no need to preserve the inode. The mmap()
> is private, but no, Linux does not keep a backup copy of the shared
> library if you overwrite it. The behaviour of overwriting the backing
> store of a private mapping is explicitly undefined.
Right, but isn't "cp -f" doing exactly that --- deleting the old one and
installing the new one?
[ experiments a bit... ] Oh, that's interesting. I was under the
impression that "cp -f" would always unlink the target file, but
on my machine (reasonably up-to-date Fedora 5, x86_64), this happens
only if it can't do open("foo", O_WRONLY|O_TRUNC). If the existing
file is overwritable then there is no difference between cp and cp -f
... and *both* crash the backend. If I "chmod -w" the .so file so that
cp -f is forced to unlink it first, then the backend does not crash!
This is at variance with what Merlin reported --- so I'm asking again
just what platform he's on. He might want to strace cp to see whether
it's doing an unlink or not in his scenario.
Anyway, on my machine, the behavior is consistent with Martijn's theory.
I suspect the kernel is effectively unmapping the .so when the
overwrite occurs, and then dlsym() naturally SIGSEGV's while trying to
look into the mapped area. If so, the early-PG_fini-lookup approach
wouldn't really fix anything.
The best solution for Merlin is probably to do "rm" then "cp" to install
a new version of the .so, instead of relying on "cp -f" to do it safely.
regards, tom lane
