Simon McVittie [Wed, 29 Jun 2011 16:29:16 +0000 (17:29 +0100)]
_dbus_server_new_for_domain_socket: don't try to unlink abstract sockets
Our abstract socket names look like filenames (/tmp/dbus-MwozdykBNK or
whatever), so if we incorrectly unlink the abstract socket name, in
highly unlikely circumstances we could accidentally unlink a non-abstract
socket belonging to another process!
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38656 Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Simon McVittie [Wed, 29 Jun 2011 15:44:33 +0000 (16:44 +0100)]
bus signal_handler: call _exit in the unlikely event that the pipe is full or invalid
On OSs with abstract sockets, this is close enough. On OSs without
abstract sockets, this results in failing to clean up Unix sockets
in /tmp if someone has sent us thousands of SIGHUP signals since we
last entered the main loop - I think that's acceptable.
The reload pipe should never get closed, but if it is for some reason,
we want a SIGTERM after that to cause an exit too.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38656 Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Simon McVittie [Wed, 27 Jul 2011 14:59:53 +0000 (15:59 +0100)]
cmake: always enable GNU and recent-POSIX extensions, like autoconf does
If the C library is (e)glibc, this allows use of POSIX, BSD, SVID, GNU,
etc., extensions to ISO C, regardless of using -ansi or not.
Not doing this broke the cmake build on Linux since commit 18b08180,
which added AC_USE_SYSTEM_EXTENSIONS to configure.ac (and removed
_GNU_SOURCE from files that use it) without also updating the cmake
build system. SO_PEERCRED is defined unconditionally, but struct ucred
is considered to be a GNU extension, so can't be used under _GNU_SOURCE.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=29228 Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Simon McVittie [Thu, 21 Jul 2011 15:17:35 +0000 (16:17 +0100)]
spec: define unicast messages and broadcast signals, and explicitly allow unicast signals
I believe that the wording of the spec has always allowed unicast signals,
but most bindings assume that signals are broadcasts, so it seems worth
saying specifically that this feature exists and can be useful.
Simon McVittie [Thu, 21 Jul 2011 15:14:02 +0000 (16:14 +0100)]
spec: make the Match Rules section true again
The spec previously claimed that only messages matching the client's
match rules would be received. This is not actually true: messages
listing a client as their DESTINATION are always delivered (security
policy permitting).
Simon McVittie [Wed, 15 Jun 2011 13:22:42 +0000 (14:22 +0100)]
test: promote GLIB_CFLAGS, DBUS_GLIB_CFLAGS to top level and use AM_CPPFLAGS
INCLUDES is a deprecated way to get the same effect as AM_CPPFLAGS.
It's harmless to add extra -I directories to all the tests, even those
that use neither GLib nor dbus-glib, so we can simplify by setting these
AM_CPPFLAGS for the whole directory.
If we change the default assumption to be that new tests will be
dynamically-linked to libdbus, those tests can be useful for
installcheck or even for installation. Accordingly, explicitly use
new variable $(static_cppflags) for all tests that need static linking.
Simon McVittie [Wed, 15 Jun 2011 13:14:34 +0000 (14:14 +0100)]
bus: use AM_CPPFLAGS to simplify preprocessor invocation
Everything in this directory is statically linked to libdbus-internal,
so we can make -DDBUS_STATIC_BUILD global. Also, merge INCLUDES into
AM_CPPFLAGS (it's an older name for the same functionality).
Simon McVittie [Wed, 15 Jun 2011 10:50:33 +0000 (11:50 +0100)]
Simplify linking for tests that use libdbus-testutils
This is the library used by tests that link libdbus-internal and DBusLoop.
By linking libdbus-internal into it, we can avoid having to repeat that
dependency all over the place - libtool and cmake both know how to follow
recursive dependencies.
In cmake, also use libdbus-testutils for more tests, in preference to
repeating its source files.
Simon McVittie [Wed, 15 Jun 2011 10:41:27 +0000 (11:41 +0100)]
Don't explicitly link thread and network libs into various tests
These tests get everything they need from the public or internal API of
libdbus-internal.la, and libtool knows how to pull in libraries'
dependencies, so we don't need explicit linking.
spawn-test and break-loader don't actually need test-utils.[ch]
either.
Simon McVittie [Fri, 29 Jul 2011 10:09:02 +0000 (11:09 +0100)]
Rename DBUS_CLIENT_LIBS to LIBDBUS_LIBS to more accurately reflect its meaning
This does still need to be in configure.ac, because it's common to
dbus/Makefile.am (linking the static/shared library) and dbus-1*.pc.in
(telling static library users which additional libraries they must link).
Simon McVittie [Wed, 15 Jun 2011 09:34:49 +0000 (10:34 +0100)]
tools: simplify linking
* dbus-send, dbus-uuidgen only need to link libdbus; libtool knows what
extra libraries libdbus depends on
* dbus-monitor uses a Winsock header (on Windows) so it needs
NETWORK_libs,but still doesn't need threads
* dbus-launch needs X (on Unix) but doesn't directly need threads or
networking
activation: add /lib/dbus-1/system-services to the search path for services
In order to allow D-Bus usage during early boot (where /usr is not
accessible) also search for bus activation files in
/lib/dbus-1/system-services/. This is only a first step in the right
direction, before we really can boot without /usr we'd need to move all
current activation files (or possibly replace
/usr/dbus-1/system-services to a symlink to
/lib/dbus-1/system-services).
Simon McVittie [Fri, 11 Mar 2011 13:24:08 +0000 (13:24 +0000)]
Add a regression test that can reproduce fd.o #34393
The number of messages is arbitrary; the more messages, the more likely
the crash is. 2000 messages seem to cause it reliably on this laptop,
but I've set it to 10000 to be safe.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
Simon McVittie [Fri, 29 Apr 2011 14:08:53 +0000 (15:08 +0100)]
Remove the per-connection link cache
With fd.o#34393 fixed, retaking the lock to cache unused links
significantly adds to locking overhead (-18% throughput in a synthetic
benchmark on an ARM device). The cache is also unlimited in size, and
probably contributes to memory growth and fragmentation by not being
under the system malloc's control.
Fixing fd.o #34393, but also dropping this cache entirely, turns out to
lead to a 5% increase in throughput on the same synthetic benchmark.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
Simon McVittie [Fri, 25 Feb 2011 17:46:54 +0000 (17:46 +0000)]
Don't finalize sent or dispatched messages while under the connection lock
Finalizing a message can trigger callbacks; that's bad, if we have a
connection locked.
In particular, if a message is received by the "left side", passed to
the "right side" and sent (as in test/relay.c (see the diagram there)
or in dbus-daemon), then finalizing that message could result in the
live messages counter for the left side, and the outgoing messages counter
for the right side, both being decremented while under either side's
lock.
After a message is dispatched on the left side, finalizing it now drops
the lock temporarily, to avoid this problem.
After a message is sent on the right side, finalizing it is now deferred
until the right side unlocks, by moving it to a new queue of
"expired messages" which is automatically cleared every time we release
the lock.
The "live messages" counter for the "left" connection will now explicitly
take the left connection's lock before decrementing, to avoid
manipulating watches without a lock.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
Simon McVittie [Fri, 25 Feb 2011 17:21:44 +0000 (17:21 +0000)]
When attaching counters to messages, don't automatically notify callbacks
In all the places where counters are added, we're under a lock. The caller
knows what effect adding the counter might have, and can replicate it
in a lock-safe way if necessary.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
Simon McVittie [Fri, 25 Feb 2011 17:08:59 +0000 (17:08 +0000)]
Comment some places where it's OK to unref a message despite holding locks
In general, dbus_message_unref should be avoided while holding locks,
because it can invoke arbitrary user callbacks (via attached data, or
via DBusCounter).
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
Simon McVittie [Tue, 14 Jun 2011 09:10:24 +0000 (10:10 +0100)]
man pages: replace all unescaped hyphen/minus characters with \-
In a man page, "-" officially means a typographical (Unicode) hyphen,
which frequently breaks the ability to copy and paste code examples from
a man page. "\-" means the ASCII hyphen/minus character. See
<http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html> for
more details.
Rather than trying to distinguish between hyphens, em-dashes and
hyphen/minus, I just replaced all ambiguous hyphens with \- by applying
this vim command repeatedly until it didn't find anything:
%s/\(^\|[^\\]\)-/\1\\-/g
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38284 Reviewed-by: Lennart Poettering <lennart@poettering.net>
projects / thirdparty / dbus.git / log
