[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1843807 - /subversion/trunk/subversion/libsvn_subr/sysinfo.c

From: Branko Čibej <brane_at_apache.org>
Date: Sun, 14 Oct 2018 16:06:30 +0200

On 14.10.2018 15:49, Daniel Shahaf wrote:
> brane_at_apache.org wrote on Sun, 14 Oct 2018 02:53 +0000:
>> Author: brane
>> Date: Sun Oct 14 02:53:08 2018
>> New Revision: 1843807
>> URL: http://svn.apache.org/viewvc?rev=1843807&view=rev
>> Log:
>> Restrict the loaded-library list on Linux to shared libraries.
>> * subversion/libsvn_subr/sysinfo.c (linux_shared_libs):
>> Show only mapped files that start with an ELF header that has
>> the correct type.
> I wonder if this isn't a bit too much. I don't want to have to deal
> with bug reports about 'svn --version --verbose' returning an error
> because the format of /proc/$pid/maps changed, about shared libraries
> not being listed in the output because their ELF magic bytes are
> different, and so on.

If the format of /proc/$pid/maps changes, our parser will ignore things
it doesn't understand. The format would have to change in very
unfortunate ways to break the checks in the code; that's not likely to
happen. This pseudo-file is a published API, changing the format in a
non-backward-compatible way would break a lot of other things before

These ELF magic bytes (the identification and type) won't change. Or
rather, they're as likely to change as Linux is likely to stop using
ELF. When that happens, we're sure to know in advance.

Regarding errors ... we don't return errors from these functions, we
ignore them on purpose, precisely so that 'svn --version --verbose'
won't throw an error. It's conceivable that we get a segfault because
the addresses in the maps file are wrong ... but that's as likely as
getting a bad pointer from the equivalent Windows or macOS functions. I
wouldn't loose sleep over that.

> It's not clear to me what functionality we gain in exchange for this
> complexity and maintenance cost. mmap() things that aren't .so, or that
> are .so but were mapped manually as opposed to by the runtime linker,
> won't be listed?

There's no difference between "mapped manually" and "mapped by the
runtime linker." The files on disk start with the ELF header, and that's
just mapped into memory. I would like to avoid is showing things like
cached JIT-compiled code and similar things that have nothing to do with

-- Brane
Received on 2018-10-14 16:06:40 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.