The newly-introduced functions, g_content_type_get_symbolic_icon() and
g_content_type_get_generic_icon_name() don't seem to be for Windows, at
least for now. So filter them out from gio.symbols on Windows.
Also, glocalfileinfo.c calls g_content_type_get_symbolic_icon() in
get_icon(), so only build that code when on Unix, for the time being.
https://bugzilla.gnome.org/show_bug.cgi?id=684278
Adding the --sourcedir option fixes these:
/path/to/src/gio/tests/test2.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test3.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test4.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
Some programs attempt to use libglib (or even libgio) when setuid.
For a long time, GTK+ simply aborted if launched in this
configuration, but we never had a real policy for GLib.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
This patch adds a private function g_check_setuid() which is used to
first ensure we don't run an external dbus-launch binary if
DBUS_SESSION_BUS_ADDRESS isn't set.
Second, we also ensure the local VFS is used in this case. The
gdaemonvfs extension point will end up talking to the session bus
which is typically undesirable in a setuid context.
Implementing g_check_setuid() is interesting - whether or not we're
running in a privilege-escalated path is operating system specific.
Note that GTK+'s code to check euid versus uid worked historically on
Unix, more modern systems have filesystem capabilities and SELinux
domain transitions, neither of which are captured by the uid
comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-By: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
g_dbus_connection_call_with_unix_fd_list_sync () and
g_dbus_connection_call_sync () should allow None for the
bus_name parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=683771
Signed-off-by: Richard Hughes <richard@hughsie.com>
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
If the interface given cannot be matched, `iface_obj' was left uninitialized and
the iface_obj == None check would end up crashing:
Traceback (most recent call last):
File "/usr/bin/gdbus-codegen", line 41, in <module>
sys.exit(codegen_main.codegen_main())
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 175, in codegen_main
apply_annotations(all_ifaces, opts.annotate)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 146, in apply_annotations
apply_annotation(iface_list, iface, None, None, None, None, key, value)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 64, in apply_annotation
if iface_obj == None:
UnboundLocalError: local variable 'iface_obj' referenced before assignment
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683088
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
There was a /* XXX */ in the code here to do proper typechecking of the
GVariant in the menu model when using g_menu_model_get_item_attribute().
We have g_variant_check_format_string() now, so use it.
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...."
If a named pipe is being read in message mode and the next message is
longer than the nNumberOfBytesToRead parameter specifies, ReadFile
returns FALSE and GetLastError returns ERROR_MORE_DATA.
Since the API doesn't allow to return both a GError and the number of
bytes read so far, it makes more sense to return nread, and let the
client call GetLastError() himself to check if ERROR_MORE_DATA.
The current alternative loses the nread information.
https://bugzilla.gnome.org/show_bug.cgi?id=679288
Any file handle created with FLAG_OVERLAPPED must have
ReadFile()/WriteFile() called with an OVERLAPPED structure.
Failing to do so will give unspecified results, invalid read/write or
corruption.
Without FLAG_OVERLAPPED, it is not possible to read and write
concurrently, even with two seperate threads, created by 2 input and
output gio streams. Also, only with FLAG_OVERLAPPED may an IO
operation be asynchronous and thus be cancellable.
We may want to call ReOpenFile() to make sure the FLAG is set, but
this API is only available since Vista+.
According to MSDN doc, adding the OVERLAPPED argument for IO operation
on handles without FLAG_OVERLAPPED is allowed, and indeed the existing
test still passes.
v2:
- update GetLastError() after _g_win32_overlap_wait_result ()
- split the unrelated ERROR_MORE_DATA handling
https://bugzilla.gnome.org/show_bug.cgi?id=679288
It is not great if calling g_permission_acquire on a simple
permission object just segfaults. This commit arranges for
this to return a G_IO_ERROR_NOT_SUPPORTED error.
-glib/gmarkup.c: Use G_VA_COPY() instead of va_copy() as va_copy() may not
be universally available.
-gio/gtestdbus.c: Include io.h on Windows for close()
In order to be able to cope with the introspection XML
from the Telepathy specification, which uses attributes
like tp:type and tp:name-for-bindings, we need to ignore
unknown attributes when parsing.
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=665634
Using GIO here may cause the gvfs module to be loaded, which
in turn gets onto the session bus to talk to gvfsd - not ideal
if you are trying to control the session bus life cycle. Instead,
just use old-fashioned glib file utils.
Solaris/OpenSolaris/OpenIndiana define FIONREAD in sys/filio.h.
This commit adds a configure check for this header, and includes
it conditionally in gio/gsocket.c.
Patch by Fabian Groffen, bug 675524.
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
The extra newline chars in the local implementation of g_application_command_line_print and g_application_command_line_printerr() cause an unwanted newline after printed strings. This patch removes the newline chars to make the functions consistent with their documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=680459
* A certificate sorta acts as a public key, but more specifically
it contains a public key (in its subjectPublicKeyInfo) field.
* Documentation was confusing and could have read like the
certificate and certificate-pem properties were returning the
public key part of the certificate.
https://bugzilla.gnome.org/show_bug.cgi?id=681158
GThreadPool defaulted to 0 for max_unused_threads (meaning thread-pool
threads would exit immediately if there was not already another task
waiting for them), and 0 for max_idle_time (meaning unused threads
would linger forever, though this is only relevant if you changed
max_unused_threads).
However, GIOScheduler changed the global defaults to 2 and 15*1000,
respectively, arguing that these were more useful defaults. And they
are, so let's use them.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
When creating a directory fails for some reason other than
the parent not existing, don't clear the error before we try
to propagate it.
To reproduce, run 'ostadmin init' on /ostree or otherwise try to
run the function on a directory with a parent directory where the
current user is not allowed to write.
https://bugzilla.gnome.org/show_bug.cgi?id=680823
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
gcontenttype.c was split into gcontenttype.c and gcontenttype-win32.c
in commit 32192ee9 ("Split gcontenttype.c"), so we don't want to include
gcontenttype.c in the Visual C++ build as it is no longer a source file
meant for Windows.
Thanks to Thomas H.P. Anderson for pointing this out.
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.
Rather than implementing GCancellableSource by polling on its fd,
implement it by just waking its GMainContext up from the "cancelled"
signal handler, thereby helping to reduce file descriptor usage.
Suggested by Ryan Lortie.
https://bugzilla.gnome.org/show_bug.cgi?id=680121
* GCancellable can be "cancelled" more than once if
g_cancellable_reset() is called.
* Don't assume that because the "cancelled" signal fired
it won't fire again.
https://bugzilla.gnome.org/show_bug.cgi?id=680111
g_async_initable_real_init_finish() was previously handling all
GSimpleAsyncResults, even if they weren't created by
g_async_initable_real_init_async(), and libnm-glib accidentally relied
on that behavior. So remove the g_simple_async_result_is_valid()
check.
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
Rather than doing a two step first-check-the-GAsyncResult-subtype-then-
check-the-tag, add a GAsyncResult-level method so that you can do them
both at once, simplifying the code for "short-circuit" async return
values where the vmethod never gets called.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
Finish deprecating the "handle GSimpleAsyncResult errors in the
wrapper function" idiom (and protect against future GSimpleAsyncResult
deprecation warnings) by adding a "legacy" GAsyncResult method
to do it in those classes/methods where it had been traditionally
done.
(This applies only to wrapper methods; in cases where an _async
vmethod explicitly uses GSimpleAsyncResult, its corresponding _finish
vmethod still uses g_simple_async_result_propagate_error.)
https://bugzilla.gnome.org/show_bug.cgi?id=667375https://bugzilla.gnome.org/show_bug.cgi?id=661767
Originally, the standard idiom with GSimpleAsyncResult was to handle
all errors in the _finish wrapper function, so that vmethods only had
to deal with successful results. But this means that chaining up to a
parent _finish vmethod won't work correctly. Fix this by also checking
for errors in all the relevant vmethods. (We have to redundantly check
in both the vmethod and the wrapper to preserve compatibility.)
https://bugzilla.gnome.org/show_bug.cgi?id=667375https://bugzilla.gnome.org/show_bug.cgi?id=661767
The "mainloop_barrier" in copy_async_thread() is unnecessary, since
the g_simple_async_result_complete_in_idle() will be queued after all
of the g_io_scheduler_job_send_to_mainloop_async()s, and sources with
the same priority will run in the order in which they were queued.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
The in commit b79fbc5c3f for fixing
-Wstrict-aliasing warnings was a little too brutal, make it a bit
better.
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
Prevent attempts to access keys ending with slashes that exist in the
schema file as references to child schemas.
Also: don't emit change signals for these same keys.
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>
Most changes were just replacing usage of "has_key" with "in".
Also updated the sorting function which was simplified and
changed to a "key" function instead of "cmp" (which is no longer
supported in python3. Verified everything builds with
python 2.7 and 3.
https://bugzilla.gnome.org/show_bug.cgi?id=678066
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
We need to ignore the defaults.list item only when there
was a mimetype handler found in a previous mimetype, not
if one was found for the same mimetype as the one that
is listed in defaults.list (same for the new-style defaults).
There was an issue when looking up the default handler
for a type where a supertype was listed in defaults.list.
We would pick the default for the parent type even if
there was a handler for the more specific type.
In the case of the new-style defaults marking (
"Default Applications" in mimeapps.list) we were already
checking for a more specific handler befor using a default,
but we also need to do a similar check for the defaults.list
case.
https://bugzilla.gnome.org/show_bug.cgi?id=678944
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
In general, code using g_slist_delete_link() is broken, because it
potentially requires an O(n) traversal. Just switch to GList in this
case.
The performance hit here was exacerbated by the fact that we were
holding a mutex that needed to be accessed by all threads.
https://bugzilla.gnome.org/show_bug.cgi?id=678576
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.
The bash-completion code nowadays expects completion files to
be installed in /usr/share/bash-completion/completions, and
expects them to be named like the command they are completing
for.
https://bugzilla.gnome.org/show_bug.cgi?id=677782
-gconverterinputstream.c: Avoid GCCism by not using non-standard pointer
arithmetic on void*, but do a cast to char * as that seems to be what the
variable was used for.
-gtestdbus.c: Don't include unistd.h unconditionally, and use g_usleep()
instead of usleep(), as usleep() is not universally available.
The "-framework" linker flag takes a second word as a parameter. If
they are passed separated with whitespace, some flag-handling routines
may not know to keep the two words together as a single unit. Use
-Wl,, to pass multiple words without embedded whitespace.
https://bugzilla.gnome.org/show_bug.cgi?id=566994
Reading from a GConverterInputStream with both input_buffer and
converted_buffer non-empty would return bogus data (the data from
converted_buffer would essentially get skipped over, though the
returned nread reflected what the count would be if it hadn't been).
This was never noticed before because (a) it can't happen if all of
your reads are at least as large as either the internal buffer size or
the remaining length of the stream (which covers most real-world use),
and (b) it can't happen if all of your reads are 1 byte (which covers
most of tests/converter-test). (And (c) it only happens for some
converters/input streams.) But this was happening occasionally in
libsoup when content-sniffing a gzipped response, because the
SoupContentSnifferStream would first read 512 bytes (to sniff), and
then pass through larger reads after that.
Fixed and added a test to converter-test.
https://bugzilla.gnome.org/show_bug.cgi?id=676478
When the application is using its D-Bus backend, it is useful to be able
to export extra D-Bus objects at the right time, i.e. *before* the application
tries to own the bus name. This is accomplished here by adding a hook
in GApplicationClass for this; and a corresponding hook that will be called
on unregistration to undo whatever the register hook did.
Bug #675509.
I didn't do this comprehensively, since there's a lot of it, mainly
due to the GDBus object manager stuff, but anyone trying to use
that would fail fast due to lack of the gdbus code generator.
My main goal was to get API additions to existing classes like
g_data_input_stream_read_line_utf8(), as well as the lower level new
API like glib-unix.h.
https://bugzilla.gnome.org/show_bug.cgi?id=676816
Using a caller-supplied buffer for g_input_stream_read() doesn't
translate well to the semantics of many other languages, and using a
non-refcounted buffer for read_async() and write_async() makes it
impossible to manage the memory correctly currently in
garbage-collected languages.
Fix both of these issues by adding a new set of methods that work with
GBytes objects rather than plain buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=671139
Rather than depending on the host's DNS configuration to properly
return an error for a non-existent hostname, just substitute in
a dummy GResolver implementation that does it for us.
GFile doesn't handle some "real" URIs, so check if there's a default
handler for the URI scheme first, and only use g_file_new_for_uri()
and g_file_query_default_handler() if not. Eg, this fixes the case of
opening http URIs with "%2F" in the path.
https://bugzilla.gnome.org/show_bug.cgi?id=666386
This essentially adds an accessor for the MimeType field in desktop files,
to retrieve the list of all mime types supported by an application.
The interface though is part of GAppInfo, so it could be implemented
in the future by other backends.
https://bugzilla.gnome.org/show_bug.cgi?id=674111
The logic here is pretty twisted, but basically we were leaking a ref
for each non-existent parent. The clearest way to fix this was to
move to more explicit refcounting logic; when a variable is pointing
to an object, it holds a ref.
https://bugzilla.gnome.org/show_bug.cgi?id=675446
Provide public access to the GDBusConnect and object path that
GApplication is using. Prevents others from having to guess these
things for themselves based on the application ID.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
g_output_stream_write_async() was not initializing the newly-added
members of the WriteData structure, causing various problems.
Also, g_input_stream_read_async() was now leaking its cancellable. Fix
that as well.
https://bugzilla.gnome.org/show_bug.cgi?id=674612
If the launch context is a GAppLaunchContext, and not a
GdkAppLaunchContext, then g_app_launch_context_get_display will return
NULL because the get_display virtual method is undefined. The DISPLAY
might still be inherited from the parent process, in which case
overwriting it with NULL breaks the launch.
This is a regression introduced in:
de834bed30
Fixes: https://bugzilla.gnome.org/672786
Commit f084b60377 incorrectly set
DIST_SUBDIRS for the toplevel Makefile.am. In general actually we
don't need to set it, because modern automake automatically sets
it by looking at conditionals for SUBDIRS.
Tested-by: Rico Tzschichholz <ricotz@t-online.de>
https://bugzilla.gnome.org/show_bug.cgi?id=667806
If all members of GSocketFamily are supported on the platform, then
all of its values will be positive, and so the enum might become
unsigned, in which case testing for "family < 0" might cause warnings.
But we want to return an error if family == 0 (aka
G_SOCKET_FAMILY_INVALID) anyway, so just tweak the test accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=674592
gdbus-daemon-generated.[ch] failed to build because it depended
on gdbus-2.0/codegen/gdbus-codegen which was build during the SUBDIRS part
of the build, however SUBDIRS are done *after* processing BUILT_SOURCES,
and these files are in BUILT_SOURCES.
The fix is simple, instead of running the gdbus-codegen code we
run the gdbus-codegen.in code, which works fine for uninstalled execution.
I also removed Makefile from the dependencies to avoid rebuilding the file
in tarballs, as Makefiles are written at configure time. We should be able to
ship the prebuilt files in the tarballs.
When running uninstalled
Add two new methods to GProxyAddress for recovering information about
the destination URI that the proxy was created for (and modify
GProxyAddressEnumerator to set that information when creating the
GProxyAddress).
In the async case, a failed DNS lookup was causing the proxy
resolution to bail out immediately, rather than just moving on to the
next potential proxy (which might not need us to do the DNS lookup
beforehand). Fix that.
This is mostly complete, sans support for activation. However, its
not as picky as the libdbus implementation in terms like validation
and limits checking, nor is it as tested.
Its can be useful to test gdbus if dbus-daemon is not availible, but
its main reason for existance is to implement a default session bus
on win32 so that e.g. GApplication is guaranteed to work.
If a GInputStream does not provide a read_async() implementation, but
does implement GPollableInputStream, then instead of doing
read-synchronously-in-a-thread, just use
g_pollable_input_stream_read_nonblocking() and
g_pollable_input_stream_create_source() to implement an async read in
the same thread. Similarly for GOutputStream.
Remove a bunch of existing read_async()/write_async() implementations
that are basically equivalent to the new fallback method.
https://bugzilla.gnome.org/show_bug.cgi?id=673997
Implement GPollableInputStream in GMemoryInputStream and
GConverterInputStream, and likewise implement GPollableOutputStream in
the corresponding output streams.
https://bugzilla.gnome.org/show_bug.cgi?id=673997
Move g_pollable_source_new() here from gpollableinputstream.c, add
g_pollable_source_new_full(), and add some new methods to do either
blocking or nonblocking reads depending on a boolean argument.
https://bugzilla.gnome.org/show_bug.cgi?id=673997
Make g_pollable_input_stream_read() and
g_pollable_output_stream_write() look a little bit more like the
non-pollable versions in terms of error handling, etc. Also, use the
read_fn and write_fn virtual methods directly rather than calling
g_input_stream_read()/g_output_stream_write(), to avoid problems with
re-entrancy involving the "pending" flag.
Also belatedly add single-include guards to the header files.
https://bugzilla.gnome.org/show_bug.cgi?id=673997
The loop was using a GConverterResult variable where it meant to use a
gssize, and since GConverterResult was ending up as an unsigned type,
this meant the (res < 0) check always failed.
Resources are always little endian, so the gvdb is byteswapped. When looking
up the value, it would return a new byteswapped variant, making the data
returned from do_lookup() invalid once that variant is unref'd. Since
byteswapping doesn't matter for the "ay" data anyway, just use
gvdb_table_get_raw_value() instead and only byteswap the length and flag
values.
https://bugzilla.gnome.org/show_bug.cgi?id=673409
* 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
This patch solves two problems:
First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).
Second, the tests are entirely pointless to build if cross-compiling.
It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
https://bugzilla.gnome.org/show_bug.cgi?id=667806
For quite some time the recommended usage of GSettings and dconf has
been to use paths like /org/gnome/example/. Use of /apps/ has spilled
over from GConf and is continuing to make its way into a number of
applications as they port.
glib-compile-schemas will now warn about these types of paths being
used. This generates a lot of noise, but hopefully it will reduce the
number of ported applications making this mistake.
Turns out libdbus doesn't send struct ucred credentials on linux, but
just relies on the SO_PEERCRED support. However, gdbus does send, and
expect to recieve a ucred credential. So, when libdbus talks to a
gdbus server the authentication fails to send the credentials.
We fix this by falling back to g_socket_get_credentials() if we don't
get any credential messages.
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>
D-Bus arrays are serialized as follows:
1. align to a 4-byte boundary (for the length)
2. uint32: the length of the serialized body in bytes
3. padding for the alignment of the body type (not included in the length)
4. the body.
Note that 3. is a no-op unless the body type is an 8-byte aligned type
(uint64, int64, double, struct, dict_entry), since you are always on a
4-byte boundary from aligning and writing the length.
So, an empty aax (that is, an array containing zero arrays of int64)
is serialized as follows:
1. align to a 4-byte boundary
2. length of the contents of this (empty) array, in bytes (0)
3. align to a 4-byte boundary (the child array's alignment requirement)
4. there is no body.
But previously, GDBus would recurse in step three to align not just for
the type of the child array, but for the nonexistent child array's
contents. This only affects the algorithm when the grandchild type has
8-byte alignment and the reader happened to not already be on an 8-byte
boundary, in which case 4 bytes were spuriously skipped.
https://bugzilla.gnome.org/show_bug.cgi?id=673612
Signed-off-by: David Zeuthen <davidz@redhat.com>
The code that is checking the userinfo part was accidentally
given a pointer to the end of the userinfo, so it was not
checking the right portion of the string at all.
gio/gproxyresolver.h: GProxyResolver already documented in gio/giotypes.h
gio/gtlsbackend.h: GTlsBackend already documented in gio/gtlsbackend.c
gio/gtlsclientconnection.h: GTlsClientConnection already documented in gio/gtlsclientconnection.c
gio/gtlsconnection.h: GTlsConnection already documented in gio/gtlsconnection.c
gio/gunixconnection.h: GTcpConnection already documented in gio/giotypes.h
glib/gversion.h: GLIB_CHECK_VERSION already documented in glib/gversion.c
Found these thanks to the improved gobject-introspection
GTK-Doc comment block/annotation parser.
See https://bugzilla.gnome.org/show_bug.cgi?id=672254https://bugzilla.gnome.org/show_bug.cgi?id=673385
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.
This is needed because glib-mkenums doesn't handle #ifdef values in
enums, and so it needs to have all values always defined in the enum.
When not available, define the missing values to a negative value.
g_input_stream_read() does state that it returns 0 on end of file, but
not in the Returns: line, so it's easy to miss on a quick skim-read.
g_input_stream_read_async() documents that g_input_stream_read_finish()
returns 0 on end of file, but g_input_stream_read_finish() itself does
not.
https://bugzilla.gnome.org/show_bug.cgi?id=673174
On some systems gelf.h may not be stored under the top level include
directory in which case we need to add the correct include paths in
cflags by using pkg-config(1).
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
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
Now that we're using g_simple_async_result_set_check_cancellable() we
no longer need this terrible hack of carrying the GCancellable on the
GSimpleAsyncResult using qdata. See bug 672013 for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=672013
Signed-off-by: David Zeuthen <davidz@redhat.com>
Call g_simple_async_result_set_check_cancellable() after all
GSimpleAsyncResult creation in order to take advantage of the new
reliable cancellation feature.
The guarantee of reliable cancellation fixes a bug in dbusmenu (which
was already assuming that cancellation was reliable). See this bug:
https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/953562https://bugzilla.gnome.org/show_bug.cgi?id=672013
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add a function g_simple_async_result_set_check_cancellable() to provide
a GCancellable that is checked for being cancelled during the call to
g_simple_async_result_propagate_error().
This gives asynchronous operation implementations an easy way to
provide reliable cancellation of those operations -- even in the case
that a positive result has occured and is pending dispatch at the time
the operation is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=672013
If there are no modules installed then the most appropriate thing is to
have no cachefile instead of an empty one. This unbreaks the "clean
directory after 'make uninstall'" check that automake does.
https://bugzilla.gnome.org/show_bug.cgi?id=671664
Otherwise we get criticals a'la
GLib-GIO-CRITICAL **: g_cancellable_release_fd: assertion `cancellable->priv->fd_refcount > 0' failed
when reading/writing to certain kinds of file descriptors.
Patch reviewed by Dan Winship on IRC.
Signed-off-by: David Zeuthen <davidz@redhat.com>
We were attempting to unregister our ownership of our D-Bus name even in
the case that we were non-unique (ie: we didn't actually own the name).
Rework the logic a bit to prevent that: for non-unique, we leave
impl->bus_name as NULL and we only register/unregister if it is
non-NULL.
If an application (such as Nautilus) wants to show a sidebar with
devices group into different groups such as "Devices" and "Network",
it's currently up to the application itself to do the classification
(for example by looking at the URI scheme for the activation root,
e.g. smb://).
This patch adds a new identifier G_VOLUME_IDENTIFIER_KIND_CLASS that
can be set by volume monitors and used by applications.
See https://bugzilla.gnome.org/show_bug.cgi?id=668295
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
Unix and Windows gio GSocket behaves differently when the socket is
closed by the peer. On Unix, the client receives pending data before
receiving HUP. But on Windows, the HUP may come before, resulting in
unreliable and racy code. We should have same behaviour on all
platforms.
According to MSDN documentation: "an application should check for
remaining data upon receipt of FD_CLOSE to avoid any possibility of
losing data."
https://bugzilla.gnome.org/show_bug.cgi?id=669810
For a number of reasons it might be useful to register the object paths
associated with a non-unique application so that the application can at
least field requests to its unique D-Bus name.
https://bugzilla.gnome.org/show_bug.cgi?id=647986
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)
This bug was exposed by fixing the following leak in the resources test:
==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)
==29204== 7,192 (76 direct, 7,116 indirect) bytes in 1 blocks are definitely lost in loss record 855 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 0x424E815: g_zlib_decompressor_new (gzlibdecompressor.c:270)
==29204== by 0x4228DD8: g_resource_lookup_data (gresource.c:422)
==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)
==27020== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 684 of 936
==27020== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27020== by 0x4084724: standard_malloc (gmem.c:85)
==27020== by 0x40847C7: g_malloc (gmem.c:159)
==27020== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==27020== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==27020== by 0x40B5277: g_variant_get_variant (gvariant.c:749)
==27020== by 0x4273182: gvdb_table_value_from_item (gvdb-reader.c:478)
==27020== by 0x42731E8: gvdb_table_get_value (gvdb-reader.c:509)
==27020== by 0x4228B36: do_lookup (gresource.c:280)
==27020== by 0x4228F56: g_resource_get_info (gresource.c:492)
==26427== 24 bytes in 1 blocks are definitely lost in loss record 608 of 965
==26427== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==26427== by 0x4084724: standard_malloc (gmem.c:85)
==26427== by 0x40847C7: g_malloc (gmem.c:159)
==26427== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==26427== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==26427== by 0x40BA89F: g_variant_valist_get (gvariant.c:4482)
==26427== by 0x40BAC23: g_variant_get_va (gvariant.c:4681)
==26427== by 0x40BAB29: g_variant_get (gvariant.c:4633)
==26427== by 0x4228BA5: do_lookup (gresource.c:293)
==26427== by 0x4228F51: g_resource_get_info (gresource.c:493)
Helper scripts in C can be problematic for cross compiling: the compiler
produces executables for the target platform, which the host is usually
unable to run.
https://bugzilla.gnome.org/show_bug.cgi?id=669224
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
