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>
When running the nonce-tcp and tcp-anonymous tests in one run
of gdbus-peer, or running one of them twice via command-line options
"-p /gdbus/tcp-anonymous -p /gdbus/tcp-anonymous", the one run second
would sometimes fail to connect with ECONNRESET.
Adding more debug messages revealed that in the successful case,
g_main_loop_run() was executed in the server thread first:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=53517
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: server thread: running main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=53517...
# tcp-anonymous: main thread: waiting for server thread...
but in the failing case, the main thread attempted to connect
before the call to g_main_loop_run() in the server thread:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=40659
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=40659...
# tcp-anonymous: server thread: running main loop...
(The log message "creating main loop" was immediately before
create_service_loop(), and "running main loop" was immediately
before g_main_loop_run().)
To ensure that the GDBusServer has a chance to start accepting
connections before the main thread tries to connect to it, do not
tell the main thread about the service_loop immediately, but instead
defer it to an idle.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749079
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Rather than having lots of obscure platform-based #ifdefs all over
gio, define some macros in gcredentialsprivate.h, and use those to
simplify the rest of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=701482
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
It's a recipe for race conditions and error; on some hardware
architectures one thread isn't guaranteed to see the results
of writes from another thread without a cache flush.
https://bugzilla.gnome.org/show_bug.cgi?id=700855
Install a public "gnetworking.h" header that can be used to include
the relevant OS-dependent networking headers. This does not really
abstract away unix-vs-windows however; error codes, in particular,
are incompatible.
gnetworkingprivate.h now contains just a few internal URI-related
functions
Also add a g_networking_init() function to gnetworking.h, which can be
used to explicitly initialize OS-level networking, rather than having
that happen as a side-effect of registering GInetAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
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
Because it now handles EINTR. And we should do so. While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.
https://bugzilla.gnome.org/show_bug.cgi?id=682833
This is useful in peer-to-peer connections.
With minor changes by David Zeuthen <davidz@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=662718
Signed-off-by: David Zeuthen <davidz@redhat.com>
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().
Change the wording in the docs. Clarify expectations for
(deprecated) g_thread_create().
The test was using a socket in a temporary directory, but not actually
creating that temporary directory. This worked fine on Linux since it
actually ended up using an abstract socket instead, but failed on
unixes without abstract sockets.
https://bugzilla.gnome.org/show_bug.cgi?id=657517
Otherwise, we may run into trouble as opening a peer-to-peer
connection uses a socket client, which uses a proxy resolver
which may end up using gsettings, whose dconf backend may end
up using the session bus to talk to dconfd...
... otherwise we might end up using the worker after it has been
freed. Reported by Dan Winship and Colin Walters.
This fix uncovered a bug in the /gdbus/nonce-tcp test case so "fix"
that as well to use a better way of having one thread wait for another
(using quotes for the word "fix" since it's pretty hackish to
busy-wait in one thread to wait for another).
Signed-off-by: David Zeuthen <davidz@redhat.com>
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
... this was causing a GDBus test-case to fail so now that it is
fixed, also reenable the test case.
https://bugzilla.gnome.org/show_bug.cgi?id=631379
Signed-off-by: David Zeuthen <davidz@redhat.com>
Otherwise things probably won't work in a garbage-collected world
(consider the trivial GC that never collects garbage).
This commit breaks GDBusServer ABI. No known released software is
using this code.
Signed-off-by: David Zeuthen <davidz@redhat.com>
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>
==29535== 56 (24 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 1,112 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D63A: test_nonce_tcp (gdbus-peer.c:1229)
==29535== 107 (24 direct, 83 indirect) bytes in 1 blocks are definitely lost in loss record 1,188 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D8E8: test_nonce_tcp (gdbus-peer.c:1259)
==29535== 112 (24 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 1,193 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D79A: test_nonce_tcp (gdbus-peer.c:1248)
==29535== 73 (24 direct, 49 indirect) bytes in 1 blocks are definitely lost in loss record 1,152 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804C6CE: test_peer (gdbus-peer.c:803)
Bug #628331.
==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 779 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==6793== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==6793== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==6793== by 0x412372A: g_object_constructor (gobject.c:1482)
==6793== by 0x4122E1D: g_object_newv (gobject.c:1266)
==6793== by 0x4122B93: g_object_new (gobject.c:1178)
==6793== by 0x41DB4F9: g_unix_fd_list_new (gunixfdlist.c:159)
==6793== by 0x804AADD: test_interface_method_call (gdbus-peer.c:172)
Bug #628331.
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>
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>
