On Unix, we use a pthreads mutex, which can be allocated and
initialized in global memory.
On Windows, we use a CRITICAL_SECTION, together with a call to
InitializeCriticalSection() from the constructor of a global static
C++ object (thanks to Ralf Habacker for suggesting this approach).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
From the department of "if it isn't tested, it doesn't work". I tried
compiling dbus without an assortment of optional features:
in_builddir ~/build/dbus/legacy ${MR_REPO}/configure \
--enable-developer --enable-maintainer-mode --enable-tests \
dbus_cv_sync_sub_and_fetch=no \
--disable-selinux \
--disable-inotify \
--disable-dnotify \
--disable-epoll \
--disable-kqueue \
--disable-launchd \
--disable-systemd \
--disable-libaudit \
--without-valgrind \
--disable-x11-autolaunch \
&& ...
and it resulted in -Wunused warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=64362
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
This reverses the relationship between these two functions.
Previously, dbus_threads_init() wouldn't allocate dbus_cond_event_tls
on Windows, call check_monotonic_clock on Unix, or call
_dbus_check_setuid on Unix.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
On pthreads platforms, POSIX guarantees that we can "allocate" mutexes
as library-global variables, without involving malloc. This means we
don't need to error-check their allocation - if the dynamic linker
succeeds, then we have enough memory for all our globals - which is an
important step towards being thread-safe by default. In particular,
making atomic operations never rely on DBusMutex means that we are free
to implement parts of DBusMutex in terms of DBusAtomic, if it would help.
We do not currently support any non-Windows platform that does not have
pthreads. This is unlikely to change.
On Windows, we already used real atomic operations; we can just
delete the unused global variable.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Unicode Corrigendum #9 clarifies that the non-characters U+nFFFE
(for n in the range 0 to 0x10), U+nFFFF (for n in the same range),
and U+FDD0..U+FDEF are valid for interchange, and their presence
does not make a string ill-formed.
GLib 2.36 made the corresponding change in its definition of UTF-8
as used by g_utf8_validate() and similar functions.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63072
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As Ralf pointed out, we usually use upper-case when substituting
variables (apart from "somethingdir", which Autoconf conventionally
makes lower-case for some reason).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63682
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This fixes a regression since 1.7.0: session.conf would be invalid when
generated by cmake.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63682
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
QNX has an arbitrary limit to the number of file descriptors
which may be passed in a message, which is smaller than the
current default. This patch therefore changes the default from
a hardcoded constant to a macro, which is determined at configure
time by looking at the host operating system.
[This reduces the limit from 4096 (session)/1024 (system) to 128 fds
per message on QNX, and 1024 fds per message on other operating systems.
I think the reduced session bus limit on other OSs is a reasonable change
too, given that the default hard/soft ulimits in Linux are only 4096/1024
fds per process. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61176
Reviewed-by: Simon McVittie <simon.mcvittie.collabora.co.uk>
This causes the test to fail. The assumption implicitly being made was
"if pid 1 is systemd, then every caller of _dbus_init_system_log() is a
systemd service" which is not valid for the regression test.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63163
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Also warn if we inadvertently use a function introduced since then.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Reviewed-by: Colin Walters <walters@verbum.org>
If DBUS_DISABLE_ASSERTS was turned on, and a buggy program called
dbus_connection_get_data() with a slot number less than zero (eg,
before even allocating the data slot), random memory would be
accessed and a random value returned. Anything less than zero
is not a valid slot number and should be rejected by libdbus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63127
Signed-off-by: Dan Williams <dcbw@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This function is called by _dbus_read_credentials_socket() to fetch client credentials.
Because Wine is used to check cross compiled dbus for windows, in calls to GetExtendedTcpTable()
we use table class TCP_TABLE_OWNER_PID_ALL instead of TCP_TABLE_OWNER_PID_CONNECTIONS.
This class is the only one which is available since wine 1.5.3.
https://bugs.freedesktop.org/show_bug.cgi?id=61787
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This fixes sd_booted() to actually mean "have systemd init", which we need for
_dbus_init_system_log() to decide whether systemd journal is being used.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=62585
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Windows also has numeric process IDs that fit in an unsigned long, so
there's no reason this has to be Unix-specific.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61787
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>