It doesn't really work right now because of a dbus-daemon(1) bug - see
the comment added in the TODO section of gdbusconnection.c. So revert
to old behavior. The downside is a lot of files in /tmp but right now
that's better than not being able to run tests in a loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Without this fix, the ./gdbus-connection test case occasionally fails, see
https://bugzilla.gnome.org/show_bug.cgi?id=629945#c5
like this
/gdbus/connection/basic: OK
/gdbus/connection/life-cycle: **
ERROR:gdbus-connection.c:223:test_connection_life_cycle: assertion failed:
(!quit_mainloop_fired)
cleaning up bus with pid 21794
Aborted (core dumped)
because the callback didn't happen on the same thread as where we are
running the loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Since we make message buses come and go, we need to ensure that the
singleton connection instance goes away before attempting to call
g_bus_get_sync() or similar.
Signed-off-by: David Zeuthen <davidz@redhat.com>
When under load, a one second timeout is just not enough. This can be
observed by e.g. restarting a CPU- and IO-intensive application like a
web browser with many tabs while running the test cases. Therefore,
bump the timeouts to 30 seconds.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Turns out that GDBusWorker will issue callbacks (in its own thread)
even after g_dbus_worker_stop() has been called. This would rarely
happen (and unreffing a connection is even rarer) so only saw this bug
occasionally when running the gdbus-connection test case in a loop.
Fix up this issue by maintaining a set of GDBusConnection objects that
are currently "alive" and do nothing in the callbacks if the passed
user_data pointer is not in this set.
Also attempted to fix up a race condition with
_g_object_wait_for_single_ref_do() and its use of GObject toggle
references - for now, just resort to busy waiting, thereby
sidestepping the toggle reference mess altogether.
Signed-off-by: David Zeuthen <davidz@redhat.com>
When using signed, we get complaints from gcc about comparing signed to
unsigned with -Wsign-compare. And combined with -Werror in users' CFLAGS
it breaks configure runs.
It looks like the deserialisation function in GSocketControlMessage can
potentially leak a reference to the class structure of a
GSocketControlMessage subclass (although the particular code path is
probably never hit).
Clean up the code a bit.
Also, make sure that the GUnixCredentialsMessage type is registered
before attempting deserialisation.
Closes bug #629687.
Emmanuele suggested adding G_GNUC_WARN_UNUSED_RESULT to all of the
g_date_time_add_* functions to help deal with the situation where people
may mistakenly believe that these functions are inplace modifiers.
Using the internal pcre has the side effect of exposing gregex.c to
glib.h. When we use the system one, we lose that, so we need to
explicitly include the things we use (glist, gatomic, etc..)
If a DateTime gets modified to cross the DST state from its previous
state then we want to update the DateTime to compensate for the new
offset.
In other words, if we have a DateTime defined as:
DateTime({ y: 2009, m: 8, d: 15, hh: 3, mm: 0, tz: 'Europe/London' });
and we add six months to it, the hour must be changed to 60 minutes
behind, as the DST comes into effect.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Otherwise we'll have to do:
dt = g_date_time_new_full (Y, M, D, h, m, s, tz);
tmp = g_date_time_add_usec (dt, usec);
g_date_time_unref (dt);
dt = tmp;
With its additional allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Timezone handling is complicated. Really complicated.
In order to simplify it a little bit, we need to expose the GTimeZone
structure.
First of all, we allow creating time zone information directly from the
offset and the DST state, and then pass it to the g_date_time_new_full()
constructor. We also need to clean up the mess that is UTC-vs.-localtime
for the other constructors.
We also allow creating a GTimeZone from the Olson zoneinfo database
names; a time zone created like this will be "floating": it will just
reference the zoneinfo file - which are mmap()'ed, kept in a cache and
refcounted. Once the GTimeZone has been associated with a GDateTime, it
will be "anchored" to it: the offset will be resolved, as well as the
DST state.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
