The test was assuming that all cancelled ops would finish within a
certain amount of time, but this often failed under valgrind. Instead,
just run the loop until all of the ops have actually finished.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
On slower platforms, the overhead of the 240 D-BUS Sleep calls is larger than
the current maximum of 6 seconds. A run on a Panda board sometimes fails with
ERROR:/build/buildd/glib2.0-2.33.8/./gio/tests/gdbus-threading.c:409:test_method_calls_on_proxy:
assertion failed (elapsed_msec < 6000): (7365 < 6000)
Bump maximum time to 8 seconds to be more resilient to this.
https://bugzilla.gnome.org/show_bug.cgi?id=682222
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
The async test had several problems:
- It created a proxy and did not launch a main loop, meaning that its
callback would usually not get called, or, if it did get called, the
test harness would have taken down the connection already, causing an
assertion failure when the proxy had an error.
- It was dependent on the proxy test to set up the server and would fail
because some properties were modified by that test.
https://bugzilla.gnome.org/show_bug.cgi?id=674805
* In order to add contstruct properties to an abstract base
calls, and retain ABI stability, the base class must add a
default implementation of those properties.
* We cannot add a default implementation of certificate-bytes
or private-key-bytes since certificate and private-key properties
are writable on construct-only.
This reverts commit 541c985869.
https://bugzilla.gnome.org/show_bug.cgi?id=682081
Implement test case suggested by Ryan Lortie on bug:
https://bugzilla.gnome.org/show_bug.cgi?id=679288
"There is a potential race here that's really unlikely to happen, but
here we go: We are trying to read from the same socket in two threads.
Some data comes. That causes the poll() in both threads (above) to
finish running. Then the cancellable is checked above. We now find
ourselves here. Only one thread will read the data. The other will
block on this function. Then the user may cancel the cancellable while
we are blocked here, but we will stay blocked...."
test_create_delete() assumes that if it creates a file and then
immediately deletes it, that the file monitor will notice this and
record it as a create followed by a delete. But that won't work with
GPollFileMonitor, which will just think nothing changed. So skip the
test in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=669331
This looks like it was stubbed out but not implemented; the vtable
entry dates to commit 3781343738 which
is just alex's initial merge of gio into glib.
I was working on some code that wants an asynchronous rm -rf
equivalent, and so yeah, this is desirable.
https://bugzilla.gnome.org/show_bug.cgi?id=680760
Add a test that the decompressor input streams handle truncated data
correctly. (They do; I wrote the test thinking there was a bug there,
but there isn't.)
Also, rename the "corruption" tests to "roundtrip", since "corruption"
makes it sound like we're testing how the converters deal with
corrupted data, as opposed to merely testing that they don't corrupt
data themselves. And fix the bug reference.
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
For a D-Bus property with name "Type" (fairly common), we used to
generate a GObject property with name "type-" and C accessors
get_type_() (to avoid clashing with the GType getter), set_type_()
(for symmetri).
However, the rules for GObject property names are fairly rigid and
specifically prohibit names ending in a dash.
Therefore change things so the chosen GObject property name is "type"
but preserve the naming rules for the C getter and setter (for the
same reasons: avoiding name clashing and symmetri).
This change does break the API of generated code (but only on the
GObject property level, the C symbols are not changed) but strictly
speaking the behavior was undefined since "type-" was an invalid
GObject property name.
Also add a test case for this.
Bug 679473.
https://bugzilla.gnome.org/show_bug.cgi?id=679473
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
After fixing bug 674452 this test case now reliably fails, as "ABC abc" is text
and definitively not PowerPoint. It previously worked as g_content_type_guess()
was reading beyond the boundary of the data due to specifying -1 as data
length.
Update that test case to expect a PO template instead, and add two more with a
definitive PO template syntax and some binary data. We do not currently have a
MIME magic for PowerPoint, so we cannot actually detect it with certainty, but
at least make sure that the returned MIME type is correct.
https://bugzilla.gnome.org/show_bug.cgi?id=678941
g_content_type_guess() requires specifying a valid data length. Fixes a
segfault when running the test.
Also add an explicit check for this and return XDG_MIME_TYPE_UNKNOWN when
data_size is specified as -1, to avoid crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=674452
Sometimes the poll duration in the /socket/timed_wait test is slightly lower
than the requested 100000, causing failures like
ERROR:/build/buildd/glib2.0-2.33.2/./gio/tests/socket.c:619:test_timed_wait:
assertion failed (poll_duration > = 100000): (99240 >= 100000)
FAIL
Adjust the test to also allow some jitter in the "too small" direction, similar
to the already existing span for "slightly too large".
https://bugzilla.gnome.org/show_bug.cgi?id=678881
make sure the proxy threads are in the "waiting for a connection"
state when we do the final cleanup, or else there are race conditions
involving which thread processes the GCancellable cancellation first.
