Commit Graph

61 Commits

Author SHA1 Message Date
Gabor Karsay
7e64004db0 docs: mark macros, flags, enums with percent sign 2022-03-04 16:21:55 +00:00
Emmanuel Fleury
60d2cfb6ae Fix missing initializer warning in gio/tests/gdbus-connection.c
gio/tests/gdbus-connection.c:90:1: error: missing initializer for field ‘padding’ of ‘GDBusInterfaceVTable’ {aka ‘const struct _GDBusInterfaceVTable’}
   90 | };
      | ^
2021-04-14 23:26:15 +02:00
Philip Withnall
7f905ff1fa tests: Fix non-atomic access to some shared variables
And drop the `volatile` qualifier from the variables, as that doesn’t
help with thread safety.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #600
2020-11-20 14:40:19 +00:00
Simon McVittie
500d065f3d GDBus tests: Use G_SOURCE_REMOVE, G_SOURCE_CONTINUE
The meaning of the boolean result of a GSource function is clearer if
we use these aliases.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2020-10-01 16:32:50 +01:00
Philip Withnall
2f171d0ed4 tests: Fix remaining race in gdbus-connection filter test
Commit 721e385 left one remaining race in the filter test, with a
comment associated with it. Unfortunately, the (seemingly unrelated)
changes in #1841 to `GCancellable` seem to have made this remaining race
a lot more likely to fail on FreeBSD than before.

What’s likely to have happened (although I was unable to reproduce the
failure, due to not having a FreeBSD system; I was only able to
reproduce the problem as a 3/1000 failure on Linux, which is still worth
fixing) is that the atomic write of the `FilterData.serial` to be
expected by the filter function sometimes happened after the filter
function had executed, so the expected message was dropped and didn’t
result in an update to the `FilterData` state.

Rework the test so that instead of setting some expectations (on
`FilterData`) in one thread and then checking them in another thread,
the worker thread just unconditionally returns messages from the filter
function to the main thread, and then the main thread checks whether the
expected one has been filtered.

With this change applied, the `gdbus-connection` test passes 5000 times
in a row for me, on Linux; and doesn’t seem to fail any more on the
FreeBSD CI machines over a few runs. (Previously it failed on 4/5 runs.)

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #2092
Fixes: #1957
2020-05-05 13:29:29 +01:00
Philip Withnall
721e385593 tests: Use atomics for shared data in gdbus-connection test
D-Bus filter functions run in a worker thread. The `gdbus-connection`
test was sharing a `FilterData` struct between the main thread and the
filter function, which was occasionally (on the order of 0.01% of test
runs) causing spurious test failures due to racing on reads/writes of
`num_handled`.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #480
2020-03-17 15:22:04 +00:00
Philip Withnall
0d567c784d tests: Port gdbus-connection to use g_assert_*() rather than g_assert()
g_assert() can be compiled out with G_DISABLE_ASSERT, which renders the
test rather useless.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #480
2020-03-17 15:21:51 +00:00
Bastien Nocera
8fd71dccc5 tests: Enable GDBus debug for a number of unreliable tests
As those tests keep failing in the CI, enable GDBus debugging to catch
some debug leads when the problems happen.
2019-12-11 11:04:10 +01:00
Philip Withnall
a01983f94c tests: Add a test for g_dbus_connection_get_flags()
It was added in !554 but never had a unit test.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1620
2019-08-21 19:49:06 +03:00
Sébastien Wilmet
d9a44b66af gio/tests/: LGPLv2+ -> LGPLv2.1+
A lot of tests in gio/tests/ don't have a license header.

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-29 19:53:34 +02:00
Simon McVittie
3beb67f9f3 gdbus-connection: wait up to 10s to actually send a message
We previously waited 0.25s, which should be enough even on slow machines,
but you never know; but we also now wait in 0.1s increments, so this test
should actually be faster now.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Acked-by: Matthias Clasen <mclasen@redhat.com>
2015-05-14 12:11:20 +01:00
Simon McVittie
45dae4b506 tests: replace most g_print() with g_printerr()
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:

* gio/tests/network-monitor: a manual mode that is run by
  "./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
  "./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
  in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2015-05-11 20:24:56 +01:00
Dan Winship
7e8d4145af gdbus: fix deadlock on message cancel/timeout
The gdbus GTask port introduced a deadlock because some code had been
using g_simple_async_result_complete_in_idle() to ensure that the
callback didn't run until after a mutex was unlocked, but in the gtask
version, the callback was being run immediately. Fix it to drop the
mutex before calling g_task_return*(). Also, tweak
tests/gdbus-connection to test this.

https://bugzilla.gnome.org/show_bug.cgi?id=747349
2015-04-06 12:22:07 -04:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Stef Walter
e6456bcfb6 gdbus-connection: Work around race in connection tests
GDBusConnection cleanup is inherently racy due to its use of worker
threads. Put tests that expect a NULL G_BUS_TYPE_SESSION singleton
as the first tests to work around cleanup races.

https://bugzilla.gnome.org/show_bug.cgi?id=719837
2013-12-11 07:32:03 +01:00
Stef Walter
5a5aaa203a gdbus-connection: Fix race condition in test
The test was expecting that the spawned process wouldn't start
up before the NameOwnerChanged signal was subscribed.

https://bugzilla.gnome.org/show_bug.cgi?id=711805
2013-11-23 15:20:51 -05:00
Stef Walter
91c8fb82fe gdbus-connection: Fix leaks in tests
https://bugzilla.gnome.org/show_bug.cgi?id=711802
2013-11-11 07:12:53 +01:00
Stef Walter
0d51ff79ed gdbus-connection: Fix use after free in test
https://bugzilla.gnome.org/show_bug.cgi?id=711802
2013-11-11 07:12:26 +01:00
Ryan Lortie
17ded322c5 tests: move tests to new _get_filename() API
This API was introduced to save a few lines of code here and there, so
let's start by removing a bunch from our own tests.

https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 09:03:32 -04:00
Ryan Lortie
58c6ca32aa tests: use new g_test_build_filename() API
Port most of the tests to the new g_test_build_filename() API.

https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 09:03:31 -04:00
Matthias Clasen
98a921045c Fix make check with builddir != srcdir
This broke when the tests were converted to be installable.
My apologies.
2013-05-27 21:21:55 -04:00
Colin Walters
bb1a5ca9a8 gio/tests: Fix gdbus-connection when run from "make check" 2013-05-21 09:21:21 -04:00
Matthias Clasen
142d78214d Convert remaining gio tests to installed 2013-05-20 08:46:21 -04:00
Lars Uebernickel
00f6d78125 g_dbus_connection_signal_subscribe: add path and namespace matching
https://bugzilla.gnome.org/show_bug.cgi?id=695156
2013-04-08 15:59:39 +02:00
Matthias Clasen
d4f0ae2c69 Fix distcheck
With gdbus-testserver now being a compiled program, it no longer
lives in SRCDIR.
2013-01-14 22:22:41 -05:00
Matthias Clasen
663ed23bc5 Use the C gdbus-testserver in tests 2013-01-03 13:15:15 -05:00
Ryan Lortie
1dc774a653 Remove g_type_init() calls
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().

Remove those uses, as they are no longer required.

https://bugzilla.gnome.org/show_bug.cgi?id=686161
2012-10-16 09:39:24 -04:00
Colin Walters
f7abd3ce13 Add g_spawn_check_exit_status()
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.

This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm.  And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.

https://bugzilla.gnome.org/show_bug.cgi?id=679691
2012-07-10 18:03:56 -04:00
Tomas Bzatek
032e8dabd1 gdbus: Implement g_dbus_connection_get_last_serial()
This patch brings an ability to retrieve serial number of the last
message sent within the current thread.

https://bugzilla.gnome.org/show_bug.cgi?id=676825
2012-06-06 19:44:39 +02:00
Alexander Larsson
0d9a7f2117 Remove ununsed include 2012-04-19 10:24:08 +02:00
Alexander Larsson
b77af49b0a Fix race in gdbus-connection test
We need to flush the AddMatches before even connecting to the bus, or we
risk missing the NameOwnerChanged from the new connections.
2012-04-19 10:24:08 +02:00
Xavier Claessens
415a8d81f6 Use GTestDBus in all GDBus unit tests
To make port easier, this rewrites dbus-sessionbus.c using a
GTestDBus singleton internally.

https://bugzilla.gnome.org/show_bug.cgi?id=672985
2012-04-19 10:07:39 +02:00
David Zeuthen
a6f83d73e5 Revert "Add GTestDBus object"
This reverts commit 1b5f70b5b0.
2012-04-18 13:47:51 -04:00
Xavier Claessens
1b5f70b5b0 Add GTestDBus object
This is a helper to write unit tests using a private dbus-daemon.

session_bus_up/down() are now just wrappers around a GTestDBus singleton.

https://bugzilla.gnome.org/show_bug.cgi?id=672985
2012-04-18 11:19:13 -04:00
Matthias Clasen
d036960d30 ifdef out some unused code
Nothing wrong with leaving debug spew in the code, but we should
not build it if it is not used.
2012-04-08 10:24:50 -04:00
Sjoerd Simons
f07201c314 GDBusConnection: Fix race in /gdbus/connection/life-cycle
GDBusConnection sets the closed flag in the worker thread, then adds an
idle callback (which refs the Connection) to signal this in the main
thread. The tests session_bus_down doesn't spin the mainloop, so the
"closed" signal will always fire if iterating the mainloop later (and
drops the ref when doing so). But _is_closed can return TRUE even before
signalling this, in which case the "closed" signal isn't fired and the
ref isn't dropped, causing the test to fail.

Instead simply always wait for the closed signal, which is a good thing
to check anyway and ensures the ref is closed.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661896
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
2011-10-18 13:18:09 +01:00
Antoine Jacoutot
ce0f7cafa1 Fix build with gcc-2.*.
https://bugzilla.gnome.org/show_bug.cgi?id=650884
2011-05-23 13:05:49 -04:00
Peng Huang
735fcf918e Bug 632544 – Cannot send a locked message with PRESERVE_SERIAL flag
https://bugzilla.gnome.org/show_bug.cgi?id=632544

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-12-13 13:09:38 -05:00
David Zeuthen
7036415cc1 GDBusConnection: Use correct GMainContext when invoking free functions
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>
2010-09-23 17:36:07 -04:00
David Zeuthen
71b1d738e2 GDBus: bump timeout for some tests
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>
2010-09-23 16:14:42 -04:00
David Zeuthen
1f6a9f1e2d GDBus: Move "slow" connection test cases into separate test program
Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 15:49:04 -04:00
David Zeuthen
f0b04acfd3 GDBusConnection: Avoid callbacks on finalized connection
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>
2010-09-23 15:16:56 -04:00
David Zeuthen
c3371efcaa Bug 624546 – Modification of GDBusMessage in filter function
Rework filter functions as per

 https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8

This commit breaks ABI. However, this ABI break affects only
applications using filter functions. The only known user of is dconf.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-09 13:21:35 -04:00
David Zeuthen
3ff9894826 Bug 624546 – Modification of GDBusMessage in filter function
Allow modifying a GDBusMessage in a filter function and also add tests
for this. This breaks API but leaves ABI (almost) intact - at least
dconf's GSettings backend (the only big user I know of) will keep
working.

https://bugzilla.gnome.org/show_bug.cgi?id=624546

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-05 20:37:27 -04:00
Christian Persch
a91a4a420e Plug a mem leak in gdbus-connection test
==26538== 145 (24 direct, 121 indirect) bytes in 1 blocks are definitely lost in loss record 765 of 790
==26538==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==26538==    by 0x405233C: g_malloc (gmem.c:134)
==26538==    by 0x406A57E: g_slice_alloc (gslice.c:836)
==26538==    by 0x406A60C: g_slice_copy (gslice.c:858)
==26538==    by 0x4035C5A: g_error_copy (gerror.c:160)
==26538==    by 0x41B6387: g_simple_async_result_set_from_error (gsimpleasyncresult.c:638)
==26538==    by 0x41FCDEB: g_dbus_connection_call_done (gdbusconnection.c:4808)
==26538==    by 0x41B682E: g_simple_async_result_complete (gsimpleasyncresult.c:762)
==26538==    by 0x41B686A: complete_in_idle_cb (gsimpleasyncresult.c:772)
==26538==    by 0x404DA7C: g_idle_dispatch (gmain.c:4224)
==26538==    by 0x4049FCD: g_main_dispatch (gmain.c:2119)
==26538==    by 0x404B2C1: g_main_context_dispatch (gmain.c:2672)
==26538==    by 0x404B716: g_main_context_iterate (gmain.c:2750)
==26538==    by 0x404BE7F: g_main_loop_run (gmain.c:2958)
==26538==    by 0x804B5CC: test_connection_send (gdbus-connection.c:407)
==26538==    by 0x4073D04: test_case_run (gtestutils.c:1174)

Bug #627187.
2010-08-18 00:13:41 +02:00
Christian Persch
75563e81c2 Plug a mem leak in gdbus-connection test
==25403== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 603 of 787
==25403==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==25403==    by 0x405233C: g_malloc (gmem.c:134)
==25403==    by 0x406A57E: g_slice_alloc (gslice.c:836)
==25403==    by 0x406A5C3: g_slice_alloc0 (gslice.c:848)
==25403==    by 0x4035B4E: g_error_new_literal (gerror.c:117)
==25403==    by 0x4035ED9: g_set_error_literal (gerror.c:314)
==25403==    by 0x41F6434: g_dbus_connection_close_sync (gdbusconnection.c:1284)
==25403==    by 0x804A861: test_connection_life_cycle (gdbus-connection.c:158)
==25403==    by 0x4073D04: test_case_run (gtestutils.c:1174)
==25403==    by 0x4073FC2: g_test_run_suite_internal (gtestutils.c:1223)
==25403==    by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403==    by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403==    by 0x40741FB: g_test_run_suite (gtestutils.c:1274)
==25403==    by 0x40733E5: g_test_run (gtestutils.c:877)
==25403==    by 0x804DC92: main (gdbus-connection.c:1024)

Bug #627187.
2010-08-18 00:13:41 +02:00
Christian Persch
a62a2fd8ed Plug a mem leak in the gdbus-connection test
Bug #627182.
2010-08-18 00:13:41 +02:00
David Zeuthen
8a3a4596e2 Bug 626748 – Use async methods for writing and handle EAGAIN
If sending a lot of data and/or the other peer is not reading it, then
socket buffers can overflow. This is communicated from the kernel by
returning EAGAIN. In GIO, it is modelled by g_output_stream_write()
and g_socket_send_message() returning G_IO_ERROR_WOULD_BLOCK.

It is also problematic that that we're using synchronous IO in the
shared GDBus IO thread. It means that one GDBusConnection can lock up
others.

It turns out that by porting from g_output_stream_write() to
g_output_stream_write_async() we fix the EAGAIN issue. For GSocket, we
still need to handle things manually (by creating a GSource) as
g_socket_send_message() is used.

We check the new behavior in Michael's producer/consumer test case (at
/gdbus/overflow in gdbus-peer.c) added in the last commit.

Also add a test case that sends and receives a 20 MiB message.

Also add a new `transport' G_DBUS_DEBUG option so it is easy to
inspect partial writes:

 $ G_DBUS_DEBUG=transport ./gdbus-connection -p /gdbus/connection/large_message
 [...]
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 0 on a GSocketOutputStream
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 128000 on a GSocketOutputStream
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 256000 on a GSocketOutputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 43669 bytes of message with serial 4 and
        size 20971669 from offset 20928000 on a GSocketOutputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 16 bytes of message with serial 3 and
        size 20971620 to offset 0 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 15984 bytes of message with serial 3 and
        size 20971620 to offset 16 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 16000 bytes of message with serial 3 and
        size 20971620 to offset 16000 from a GSocketInputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 144000 bytes of message with serial 3 and
        size 20971620 to offset 20720000 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 107620 bytes of message with serial 3 and
        size 20971620 to offset 20864000 from a GSocketInputStream
 OK

https://bugzilla.gnome.org/show_bug.cgi?id=626748

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-16 13:54:13 -04:00
Matthias Clasen
8246bf4bde Improve gdbus test coverage 2010-07-31 00:13:02 -04:00
David Zeuthen
d2d97a214d Bug 625584 – Crashes application on unref with signal subscription
Don't do too much work in the finalizer - in particular, there's no
need to send RemoveMatch() messages to the bus daemon since we're
going to sever the connection and the bus will garbage collect
anyway. In this case it crashed the process.

Also add a test case that checks that the appropriate GDestroyNotify
callbacks are called when unreffing a connection with either 1)
exported objects; 2) signal subscriptions or 3) filter functions
.. yes, ideally apps would unregister such callbacks before giving up
their ref but that's not how things work :-)

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-07-30 16:06:18 -04:00