Chengwei Yang [Tue, 29 Oct 2013 02:27:11 +0000 (10:27 +0800)]
Test: add test cases for message parsing
Add test cases for testing:
* If more arguments than requested are present, the requested
arguments are returned and the extra arguments are ignored.
* If arguments parse failed, ensure we didn't leak any memory or unix
fd
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=21259
[added a check for fd leaks around verify_test_message_args_ignored() -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Tue, 29 Oct 2013 14:20:00 +0000 (22:20 +0800)]
Fix memory or unix fd may leak in dbus_message_iter_get_args_valist
This is an aged bug since 2009, so let's fix it. Say if a previous
parsing for unix fd or array of string successfully but then a later
element parsing fail, then the unix fd or array of string leaked.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=21259 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Fri, 11 Oct 2013 08:35:17 +0000 (16:35 +0800)]
Correctly set number of arguments already handled
At privous, which increments the number of arguments already handled in
the last of loop, however, if there is any invalid argument, then it
will "goto out" and the number of arguments already handled is now
incorrect.
A following patch will use the number of arguments already handled as a
loop terminate condition, so it's good to fix it before.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=21259 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Wed, 23 Oct 2013 14:19:13 +0000 (15:19 +0100)]
path_namespace='/' should match everything
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=70799 Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk> Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Chengwei Yang [Wed, 9 Oct 2013 02:44:12 +0000 (10:44 +0800)]
dbus-monitor: keep backwards compatibility
eavesdropping as a match rule key introduced in DBus 1.5.6, and the
privous implementation doesn't keep backwards compatibility with older
dbus-daemon.
And the reference dbus-daemon implementation just fail if unknwon key
found in match rule, this is undefined hehavior in DBus Sepcification.
Also there is a feature request for change this hehavior to
"ignore unknown key in match rule", See
https://bugs.freedesktop.org/show_bug.cgi?id=66114
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66107 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Andrey Mazo [Tue, 8 Oct 2013 14:54:11 +0000 (15:54 +0100)]
dbus-send: replace --address with --peer and --bus.
--peer is a direct substitute for --address.
With --bus dbus-send registers on bus given by ADDRESS, thus allowing
messages to be sent to the bus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48816
[adjusted to apply to current master -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Tue, 8 Oct 2013 12:55:03 +0000 (20:55 +0800)]
Spec: document multiple .service files own the same well known name
In current dbus-daemon(1) implement, system .serivce must named after
its owned name, but this is not the case for session .service.
For session service, the result of multiple .service files own the
same well known name is undefined since readdir(3) doesn't return
dirent in a defined sequence.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66608
[added some </para><para> -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Tue, 8 Oct 2013 13:59:37 +0000 (21:59 +0800)]
Unify the way to find dbus-daemon test binary
There are two ways to find the dbus-daemon for testing. The first one is
defined as string at compile stage and the second one is export it from
test environment.
The first way has limitation that after defined, it's static string, so
it's impossible to run installable check. So let's unify to the second
way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
[added missing "}" -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Tue, 8 Oct 2013 14:54:11 +0000 (15:54 +0100)]
dbus-send: replace --address with --peer and --bus.
--peer is a direct substitute for --address.
With --bus dbus-send registers on bus given by ADDRESS, thus allowing
messages to be sent to the bus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48816
[adjusted to apply to current master -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Wed, 26 Jun 2013 02:21:31 +0000 (10:21 +0800)]
dbus-monitor: remove redundant match rules
Currently, DBus Specification only consists of four message types, so to
monitor all the types of message, no need to match all of them but just
left it empty is OK.
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66107 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Tue, 24 Sep 2013 13:25:01 +0000 (21:25 +0800)]
Do not suggest user the next step after executed autogen.sh
We assume that user/developer who building dbus from source code are
familiar with the standard 'autogen.sh, configure, make, make install'
build process, so print such a notice doesn't make a lot of sense.
In addition, on *BSD platform, the pre-installed 'make' doesn't work at
all since gnu make is required. However, it named to 'gmake' on *BSD
platform. So the notice will makes new comer confused.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65415 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Fri, 12 Oct 2012 12:53:25 +0000 (13:53 +0100)]
Add support for configuring --with-valgrind=auto
This is the configuration I'd like to use for the "debug build" of dbus
on Debian - if we use --with-valgrind=yes, we have to hard-code knowledge
of which architectures do and don't have Valgrind in two places instead
of just one.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=56925 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Chengwei Yang [Thu, 26 Sep 2013 09:35:36 +0000 (17:35 +0800)]
Fix build on NetBSD 6.1.1 with gcc 4.5.3
There are two build failure on NetBSD 6.1.1 with gcc 4.5.3, the first
one is char to int, warning treated as error. The second one is a mismatch
between format string and arguments.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69842
[adjusted commit message -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Fri, 13 Sep 2013 18:01:04 +0000 (19:01 +0100)]
_dbus_read_credentials_socket: warn or fail at compile time if no support
On a whitelist of OSs known to have working credentials-passing
(currently FreeBSD, Linux, OpenBSD and NetBSD), it would be a
regression for us to not have credentials-passing, so fail hard.
On other OSs, raise a warning, which is not normally fatal but
will alert developers on those platforms.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60340 Reviewed-by: Colin Walters <walters@verbum.org>
Simon McVittie [Fri, 13 Sep 2013 17:39:18 +0000 (18:39 +0100)]
Remove BSD-style LOCAL_CREDS support
It appears that this regressed back in 2009 (commit 7bf132c7)
and doesn't compile. Also, with patches from Matt Fischer to make
it compile again on QNX, it compiles but doesn't actually work
on NetBSD, which was the platform for which this code was added.
This might be for the reasons described in
<http://julipedia.meroh.net/2006/08/localcreds-socket-credentials.html>.
NetBSD pkgsrc has a large unsubmitted patch to use LOCAL_PEEREID, which
is analogous to Linux/OpenBSD SO_PEERCRED.
So, I think we can safely assume that nobody is relying on this:
either they implement one of our many other supported
credentials-passing mechanisms, or they're patching it locally
anyway.
LOCAL_CREDS is not actually very good - it's awkward to use, and
doesn't provide the pid, only the uid. Of the platforms known to
implement it, QNX and NetBSD both have getpeereid() which provides
just as much information, while FreeBSD and Dragonfly BSD both have
SCM_CREDS which provides the pid too. So, let's just get rid of it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60340 Reviewed-by: Colin Walters <walters@verbum.org>
Fix an incorrect sizeof which leads to allocation of more memory than
actually needed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69329
[elide redundant "* sizeof (char)" which is 1 by definition -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Wed, 5 Jun 2013 18:43:13 +0000 (19:43 +0100)]
Remove support for platforms with no 64-bit integer type
This has been a soft requirement since 1.5.0; anyone on such platforms
would have had to configure --without-64-bit, provoking a warning that
instructed them to report a D-Bus bug with details of their platform.
Nobody has done so, so if anyone still lacks a 64-bit integer type,
they're on their own.
(Also, I tried the build with --without-64-bit and it's full of
fatal compiler warnings, so it's not clear that we're actually
losing anything by removing this "feature".)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65429 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
dbus-mainloop.c: undeclared variable n_fds if define MAINLOOP_SPEW.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69410 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com> Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Mon, 16 Sep 2013 11:43:40 +0000 (12:43 +0100)]
Fix an incorrect sizeof.
Fix an incorrect sizeof which leads to allocation of more memory than
actually needed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69329
[elide redundant "* sizeof (char)" which is 1 by definition -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Mon, 2 Sep 2013 16:39:37 +0000 (17:39 +0100)]
dbus-sysdeps-win: don't include wspiapi.h
This block provoked a warning on mingw-w64 because we were redefining
_inline. According to Ralf's research, it was introduced in 452ff68a:
Windows 2000 doesn't have getaddrinfo and related functions in
ws2tcpip.h, but does have a shim implementation in wspiapi.h.
At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
why there was a __GNUC__ code path here. The "#define _inline" on that
code path looks likely to be some sort of workaround for a faulty version
of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
__GNUC__ code path and get the redefinition.
dbus no longer supports Windows 2000, so we no longer need wspiapi.h
at all, and can rely on XP or later. (Ralf's policy is to only support
versions of Windows that are still supported by Microsoft, and Windows 2000
reached the end of its life-cycle in 2010.)
Chengwei Yang [Wed, 4 Sep 2013 07:13:33 +0000 (15:13 +0800)]
Make userdb cache as a built-in feature
The disable-userdb-cache code path is never been fine tested and you
could expect an extramely slow bus if you did that. And there are known
bugs on fd.o if build without userdb cache. So to prevent user from
using bus without userdb cache, it changed to a built-in feature, no
longer optional now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66947
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=15589 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Fri, 13 Sep 2013 13:59:17 +0000 (14:59 +0100)]
Don't assume that X11 autolaunch will work if DISPLAY is unset
In practice, it won't; other forms of autolaunch (like Mac OS launchd)
might, but we can't really assert either way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40352 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[amended to reinstate use of dbus/dbus-sysdeps.h which was removed
by 412538b3b9 -smcv] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Fri, 13 Sep 2013 08:56:26 +0000 (16:56 +0800)]
Use test binaries in build dir to do test
When do autolaunch testing, libdbus will try to start dbus-launch in
installed direcotry, if fail then fall back to dbus-launch in $PATH.
dbus-launch does a relative better thing to start dbus-daemon in build
directory, however, in most of case, the build $prefix is different from
the real prefix where dbus-daemon installed. So dbus-daemon will fail to
start due to can't find its config file. And then dbus-launch will fall
back to finally the installed dbus-daemon.
This patch fix this behavior and will start dbus-launch and dbus-daemon
in build directory in test environment.
Justin Lee [Wed, 29 May 2013 19:21:31 +0000 (03:21 +0800)]
Remove obscure "low-latency" parts in the introduction of spec
According to Wikipedia
http://en.wikipedia.org/wiki/Latency_%28engineering%29#Packet-switched_networks
latency means "the time from the source sending a packet to the destination
receiving it". Therefore, latency is unrelated to whether the operation is
asynchronous or synchronous. And also unrelated to whether it's one-way or
round-trip. Latency exists for asynchronous and one-way transfer, because for
current DBus implementations we need at least one context switch to transfer
each message from the sender process to the receiver process. Emphasizing
D-Bus is low-latency could encourage user to abuse/misuse the system.
Mail disscusion:
http://lists.freedesktop.org/archives/dbus/2013-May/015665.html
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65141 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Allow EPROTOTYPE for SOCK_CLOEXEC but unsupported by socket/socketpair
If SOCK_CLOEXEC is defined (usually because accept4 is implemented),
check for EPROTOTYPE (the POSIX errno for invalid socket types) in
addition to EINVAL as errno indicating whether socket and socketpair
do not support SOCK_CLOEXEC (and other SOCK_* flags).
[adapted by Chengwei Yang to give _dbus_connect_exec() the same treatment]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69073 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Fri, 6 Sep 2013 05:48:38 +0000 (13:48 +0800)]
Use the argument of dbus_connection_set_route_peer_messages()
The function dbus_connection_set_route_peer_messages() take a bool
argument, however, in the implementation, it always hard-code to TRUE
rather than take its bool argument.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69165
[amended commit message -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Fri, 6 Sep 2013 03:26:44 +0000 (11:26 +0800)]
Fix pass wrong type of argument to function
The last argument of function _dbus_transport_new_for_socket() is
declared as const DBusString *. However, it is passed as a bool value.
Although the value of FALSE equals NULL in fact, this is an incorrect
use of function.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69165 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Fix a file descriptor not being closed when an error codepath is taken.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69182 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[more specific commit message -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Thu, 27 Jun 2013 01:13:57 +0000 (09:13 +0800)]
dbus-launch: unconditionally use SIGHUP and free memory on OOM
In a previous patch, it check SIGHUP for windows, however, in fact there
is dbus-launch-win.c supposed to be used on windows. So just use SIGHUP
unconditionally.
Also free memory on OOM, although this doesn't make much sense since
this is a oneshort program, rather than a daemon.
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
[fixed whitespace -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66068 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Wed, 26 Jun 2013 11:33:29 +0000 (12:33 +0100)]
Use GNU make features to reduce repetition
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48277 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Simon McVittie [Wed, 26 Jun 2013 11:27:09 +0000 (12:27 +0100)]
Document that GNU make is required
In theory the Autotools build system supports any "make" implementation,
but there are no regular contributors who test with BSD make, so the
inevitable result is that only GNU make actually works (fd.o #48277).
Apparently there's only one GNUism at the moment, which is fixable,
but that means repeating ourselves a bit more. If we instead document
that GNU make is required, we can simplify the Makefiles over time
by using extensions like $(patsubst), leading to a less error-prone
build system.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48277 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Simon McVittie [Tue, 3 Sep 2013 11:16:32 +0000 (12:16 +0100)]
Add CPPFLAGS to "shared if possible" test binaries
In principle we ought to define DBUS_STATIC_BUILD in anything that's
using libdbus-internal.la (to avoid linking failures on
statically-linked mingw builds), and DBUS_TEST_USE_INTERNAL in any
test that's using the non-dbus-glib code paths of test-utils.[ch]
(to avoid the GLib requirement, although in practice, everything
"shared if possible" requires GLib at the moment anyway).
Simon McVittie [Mon, 2 Sep 2013 15:32:31 +0000 (16:32 +0100)]
Tests: allow dbus-glib to be replaced with use of libdbus-internal
We only use dbus-glib for its main loop; within dbus, DBusLoop is
available as an alternative, although it isn't thread-safe and
isn't public API.
For tests that otherwise only use libdbus public API, it's desirable to
be able to avoid DBusLoop, so we can run them against an installed
libdbus as an integration test. However, if we don't have dbus-glib,
we're going to have to use an in-tree main loop, which might as well
be DBusLoop.
The major disadvantage of using dbus-glib is that it isn't safe to
link both dbus-1 and dbus-internal at the same time. This is awkward
for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
but only on Windows (fd.o #54445). If we use the same API wrapper around
both dbus-glib and DBusLoop, we can compile that test against dbus-glib
or against DBusLoop, depending on the platform.
Simon McVittie [Mon, 2 Sep 2013 16:14:38 +0000 (17:14 +0100)]
corrupt test: close connection before releasing GSocket
GSocket takes responsibility for closing the fd, and there doesn't
seem to be any way to tell it not to. When this test is adapted to run
under DBusLoop as an alternative to dbus-glib, that becomes a problem,
because DBusLoop/DBusSocketSetEpoll do not tolerate that. Work around it.
projects / thirdparty / dbus.git / log
