Implement GPollableInputStream in GMemoryInputStream and
GConverterInputStream, and likewise implement GPollableOutputStream in
the corresponding output streams.
https://bugzilla.gnome.org/show_bug.cgi?id=673997
* Add resolver functions for looking up DNS records of
various types. Currently implemented: MX, TXT, SOA, SRV, NS
* Return records as GVariant tuples.
* Make the GSrvTarget lookups a wrapper over this new
functionality.
* Rework the resolver test so that it has support for
looking up MX, NS, SOA, TXT records, and uses GOptionContext
https://bugzilla.gnome.org/show_bug.cgi?id=672944
When presented with an array of empty arrays of 8-byte-aligned types,
GDBus would incorrectly apply the 8-byte alignment when reading back.
https://bugzilla.gnome.org/show_bug.cgi?id=673612
Signed-off-by: David Zeuthen <davidz@redhat.com>
GDBus heavily relies on idles for some of its cleanup operations,
and not running a mainloop leads to things not getting cleaned
up properly, which in turn leads to test failures, since the
session bus singleton does not get removed.
This program is only used indirectly from gapplication.c in
tests, but that is no reason to let it segfault when it is
run from the commandline without arguments.
GDBusProxy sets an error on a GSimpleAsyncResult and then returns
without dispatching the result for completion (and leaks the result in
the process). Fix that.
Also add a testcase. Unfortunately, adding the testcase uncovered
bug #672248. We can work around that by reordering the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=672249
g_file_read() was returning G_IO_ERROR_IS_DIRECTORY when you tried to
open a directory on unix, but G_IO_ERROR_PERMISSION_DENIED on win32.
Fix that, and add a test to tests/file.c
Pointed out on IRC by Paweł Forysiuk.
https://bugzilla.gnome.org/show_bug.cgi?id=669330
This is useful when using certain D-Bus services where the
PropertiesChanged signal does not include the property value such as
e.g. various systemd mechanisms, see e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=37632
Signed-off-by: David Zeuthen <davidz@redhat.com>
==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265== at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265== by 0x408479B: standard_calloc (gmem.c:104)
==1265== by 0x4084846: g_malloc0 (gmem.c:189)
==1265== by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265== by 0x4228A98: g_resource_load (gresource.c:253)
==1265== by 0x804A56D: test_resource_registred (resources.c:198)
==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509== by 0x4084724: standard_malloc (gmem.c:85)
==509== by 0x40847C7: g_malloc (gmem.c:159)
==509== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509== by 0x804A48C: test_resource_data (resources.c:174)
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778== by 0x4084724: standard_malloc (gmem.c:85)
==28778== by 0x40847C7: g_malloc (gmem.c:159)
==28778== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778== by 0x804C2B1: test_uri_query_info (resources.c:435)
==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318== by 0x4084724: standard_malloc (gmem.c:85)
==28318== by 0x40847C7: g_malloc (gmem.c:159)
==28318== by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318== by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318== by 0x804B39E: test_resource_registred (resources.c:283)
==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820== by 0x4084724: standard_malloc (gmem.c:85)
==27820== by 0x40847C7: g_malloc (gmem.c:159)
==27820== by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820== by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820== by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820== by 0x804BCA7: test_resource_module (resources.c:370)
The glib-compile-resources --generate-dependencies call was failing,
although not stopping the build.
Failed to open file 'test2.gresource.xml': No such file or directory
Failed to open file 'test3.gresource.xml': No such file or directory
Failed to open file 'test4.gresource.xml': No such file or directory
Failed to open file 'test.gresource.xml': No such file or directory
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
It's hardly useful to bloat the resource data with blanks intended only
for human readability, so add a preprocessing option that uses xmllint --noblanks
to strip these.
Bug #667929.
struct sin6_addr has two additional fields that struct sin_addr
doesn't. Add support for those to GInetSocketAddress, and make sure
they don't get lost when converting between glib and native types.
https://bugzilla.gnome.org/show_bug.cgi?id=635554
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
This can be used for debugging, or for progress UIs ("Connecting to
example.com..."), or to do low-level tweaking on the connection at
various points in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=665805
g_main_loop_quit() only quits mainloops that are currently running --
not ones that may run in the future. The way the gdbus-threading tests
are written can possibly result in a call to g_main_loop_quit() before
g_main_loop_run() has started.
The mainloops aren't actually used for anything other than signalling
the completion of the threads, so just use g_thread_join() for that.
https://bugzilla.gnome.org/show_bug.cgi?id=666129
Have one simple _get() API that returns the group immediately, in an
empty state. The group is initialised on the first attempt to interact
with it.
Leave a secret 'back door' for GApplication to do a blocking
initialisation.
GDBusConnection now dispatches GDestroyNotify calls back to the
mainloop. Adding an idle to the mainloop is O(n) in the number of idles
already there. We therefore need to periodically empty the mainloop to
avoid quadratic behaviour with a very large 'n'.
Exporting can only be done relative to a particular given main context
and all interaction with the action group must be on that same context.
Fix up the implementation so that the user can specify that context with
the normal (thread default) mechanism and document the limitation on the
API.
Adjust the testcase to adhere to the documentation limitations. It
passes now.
Sometimes randa and randb end up having the same state, causing them to
return the same stream of 'random numbers'. This is a problem for the
testcase that is looping to find unequal menus.
If we find ourselves in this state, throw one of the random generators
away and recreate it so we have a better chance of getting some unequal
menus.
Give it the same treatment as the exporter for GActionGroup just got.
There is a wart here: the exporter attempt to re-enter GDBusConnection
when it is freed in order to cancel outstanding name watches.
GDBusConnection holds its own lock while calling the destroy notify, so
the attempt at reentrancy results in a deadlock.
We have a workaround to deal with that for now...
Rename g_application_set_menu to g_application_set_app_menu and make a
couple of fixups. Clarify the documentation about exactly what this
menu is meant to be.
Add g_application_set_menubar and document that as well.
Create a 'mirror' model of the proxy for the testcase. In addition to
testing that the proxy model emits the proper signals this also keeps
the proxy alive (by holding references to it from the mirror).
The previous code would create the submenu proxies and destroy them
right away (from the recursive step in the equality comparison
functions). This means that the subscription would go out over D-Bus
and the proxy would be destroyed before it returned. Keeping the model
alive allows it to be actually updated.
Each test needs to remove the sources that it attaches
to the default main context, or else things will work
fine in isolation, but go bad in a full test run.
There are no public 'exporter' objects, so don't allude to them
in the function names. At the same time, we want to make it clear
that these functions are D-Bus specific.
The new APIs are
g_action_group_dbus_export_start
g_action_group_dbus_export_query
g_action_group_dbus_export_stop
g_menu_model_dbus_export_start
g_menu_model_dbus_export_query
g_menu_model_dbus_export_stop
