On 32 bit systems long will overflow in 2038, causing complete breakage.
This is confirmed by running dbus's test suite on a 32 bit system
with system time set to 2040 (and configured to use 64 bit time_t of course).
Note that both timespec and timeval are specified with time_t for the
seconds component. This should propagate everywhere where that data is
passed and stored, but previously _dbus_get_monotonic_time() and
_dbus_get_monotonic_time() would truncate it to long.
Also add a function for parsing dbus_int64_t from
files, as existing functions can only handle long.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
The full license texts are not added because they were already
added in a previous commit.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
see #394
By specifying an error instance via the additional parameter, errors that
occur in it are transported to the caller in a coordinated manner.
This eliminates the need to query GetLastError() outside the function,
which can return an incorrect value if the implementation changes.
dbus-run-session starts a dbus-daemon before the client application.
We must avoid letting the application try to connect before the
dbus-daemon's DBusServer is listening for connections.
In the Unix implementation, we already achieved this via the
--print-address option. If the client tried to connect too soon,
the server would not yet be listening and the client would fail.
In the Windows implementation, we communicate the bus address to
the client application as an autolaunch: address, so if the client
tried to connect too soon, it would autolaunch a new dbus-daemon
instead of using the one that it was intended to use.
We can avoid this by using a new option to pass in a Windows event
object, which will be set when the server has started and is ready
to process connections.
Fixes#297
After the merge request !22 was created, this bug was fixed in !23,
the associated branch was used for local tests, but the fix was not
transferred to !22. After merging !22 into the master branch and
rebasing !23 to the master, this fix was lost.
Reviewed-by: Simon McVittie <smcv@collabora.com>
This should avoid test failures under CMake in which the
dbus-daemon inherits an unwanted fd from CMake's test framework, causing
the close-on-exec check before executing activated services to fail.
The dbus-daemon now marks all fds that it inherits, except for its
stdin, stdout and stderr, to be closed on exec. For completeness, the
dbus-daemons run by dbus-run-session and dbus-launch also now inherit
stdin, stdout, stderr and the pipes used to communicate with their
callers, but nothing else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
stdout and stderr are close-on-exec and buffered, so we can't rely on
their buffers being empty. If we continue to execute application code
after forking (as opposed to immediately exec()ing), then the child
process might later flush the libc stdio buffers, resulting in
output that is printed by the parent also being printed by the child.
In particular, test-bus.log sometimes grows extremely large for
this reason, because this test repeatedly attempts to carry out
legacy activation.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
Based on part of a patch from Thomas Zimmermann.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98191
DBUS_SESSION_BUS_PID is not mandatory to set, but we should unset it
if present, since it points to a different session's bus. Likewise for
DBUS_SESSION_BUS_WINDOWID.
Similarly, if DBUS_STARTER_BUS_TYPE and DBUS_STARTER_ADDRESS
are set (as they would be under GNOME Terminal 3.8, see
<https://bugs.freedesktop.org/show_bug.cgi?id=63119>) then they
are likely to point to a different session's bus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
In Linux envrionment, signal.h included by sys/wait.h, however, this
isn't the case in FreeBSD. So explicit include it to fix build failure.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66197
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
