Add functions for manipulating the environment under which a
GAppLaunchContext will launch its children, to avoid thread-related
bugs with using setenv() directly.
FIXME: win32 side isn't implemented yet
https://bugzilla.gnome.org/show_bug.cgi?id=659326
With search gaining traction as being the preferred way to locate
applications, the existing .desktop file fields meant for browsing
often produce insufficient results.
gnome-control-center introduced a custom X-GNOME-Keywords field for
that purpose, which we plan to support in gnome-shell as well.
https://bugzilla.gnome.org/show_bug.cgi?id=661763
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().
It is possible for _g_io_module_get_default() to be called recursively
(eg, if a module of one type is loaded that tries to look up gsettings
from its init() method and ends up causing the gsettings module to be
loaded). So use a recursive mutex.
If the connection to the bus is lost while a method call is ongoing,
the method call does not get cancelled. Instead it just sits around
until it times out.
This is visible here on XO laptops when stopping the display manager
during shutdown. imsettings starts sending a sync message to give up
its bus name (via g_bus_unown_name()), then systemd terminates the
session bus at approximately the same time. imsettings then hangs for
about 20 seconds before timing out the message.
http://lists.freedesktop.org/archives/dbus/2011-September/014717.html
imsettings behaviour could be improved as described in that thread,
but I think this is a glib bug. I've also come up with the attached
patch which fixes it.
Credits for the bug-fix goes to Daniel Drake <dsd@laptop.org>. The test
case was written by David Zeuthen <zeuthen@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=660637
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.
https://bugzilla.gnome.org/show_bug.cgi?id=660994
Since it is valid for a D-Bus interface / service to add new methods,
signals or properties we must NEVER warn about unknown properties or
drop unknown signals or disallow unknown method invocations when we
have an expected interface.
So this means that the expected_interface machinery is only useful for
checking that the service didn't break ABI.
Also update the docs so it is clear exactly what it means to have an
expected interface.
https://bugzilla.gnome.org/show_bug.cgi?id=660886
Signed-off-by: David Zeuthen <davidz@redhat.com>
These were the last users of the dynamic allocation API.
Keep the uses in glib/tests/mutex.c since this is actually meant to test
the API (which has to continue working, even if it is deprecated).
https://bugzilla.gnome.org/show_bug.cgi?id=660739
Add _g_io_module_get_default(), which implements the
figure-out-the-best-available-module-that-is-actually-usable logic,
and use that to simplify g_proxy_resolver_get_default(),
g_settings_backend_get_default(), g_tls_backend_get_default(), and
g_vfs_get_default().
https://bugzilla.gnome.org/show_bug.cgi?id=620932
g_file_make_directory_with_parents() will fail for already
existing directories, unlike g_mkdir_with_parents(), so mention
this clearly in the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=660791
The GIOScheduler was using a GCond in a way that didn't deal with the
possibility of spurious wakeups. Add an explicit predicate and a loop.
Problem caught by Matthias Clasen.
https://bugzilla.gnome.org/show_bug.cgi?id=660739
Make the options from an /etc/fstab entry available as public API -
this can be used to support options such as
comment=gvfs.name=Foo\040Bar
to e.g. set the name of an fstab mount in the UI to "Foo Bar".
https://bugzilla.gnome.org/show_bug.cgi?id=660536
Signed-off-by: David Zeuthen <davidz@redhat.com>
This reverts commit c841c2ce3f.
This approach has been an unmitigated disaster. We're getting all sorts
of crashes due to functions that are returning NULL because they can't
find the schema for the default value. The people who get these crashes
are then confused about the root cause of the problem and waste a lot of
time trying to figure it out.
Until we find a better solution, we should go back to what we had
before.
https://bugzilla.gnome.org/show_bug.cgi?id=655366
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
Deprecate both g_thread_create functions and add
g_thread_new() and g_thread_new_full(). The new functions
expect a name for the thread.
Change GThreadPool, GMainContext and GDBus to create named threads.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
GVDB deals with empty lists by returning NULL for the list instead of a
zero-length (non-NULL) strv. We can work around that in GSettingsSchema
by checking for the NULL case and treating it like a zero-length list.
https://bugzilla.gnome.org/show_bug.cgi?id=660147
On recent Linux distros /etc/mtab is just a symlink to /proc/mounts
and GFileMonitor does not work there because of how the kernel conveys
that the file changes.
https://bugzilla.gnome.org/show_bug.cgi?id=660511
Signed-off-by: David Zeuthen <davidz@redhat.com>
Previously, we took the default application for a particular mimetype
from the system and copied it into the user's configuration as the
default there.
Instead of doing that we leave the user's default unset, and at time of
use, if the user has no explicitly-set default value, we use the system
default.
This avoids complicated situations where inappropriate applications were
being set as the default in the user's configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
This tests the interaction between mimeinfo.cache, defaults.list and
mimeapps.list to ensure g_app_info_set_as_last_used_for_type doesn't
incorrectly change the default.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
The documentation for G_TYPE_CHAR says:
"The type designated by G_TYPE_CHAR is unconditionally an 8-bit signed
integer."
However the return value for g_value_get_char() was just "char" which
in C has an unspecified signedness; on e.g. x86 it's signed (which
matches the GType), but on e.g. PowerPC or ARM, it's not.
We can't break the old API, so we need to suck it up and add new API.
Port most internal users, but keep some tests of the old API too.
https://bugzilla.gnome.org/show_bug.cgi?id=659870
Otherwise we might collide with an interface called Connection.
https://bugzilla.gnome.org/show_bug.cgi?id=659699
This is for the same reason that GDBusProxy has its properties
prefixed with g-.
Signed-off-by: David Zeuthen <davidz@redhat.com>
We ignore entries with mountpoint of "swap" and "ignore". Add "none" to
that list, since Debian uses it.
Probably we should move to using our already-existing internal list of
things to ignore, but this patch is more minimally intrusive for now.
https://bugzilla.gnome.org/show_bug.cgi?id=654563
Commit afa82ae805 introduced a compilation
regression on BSD systems that use the sysctl(3) interface; we need to
declare the buffer len in _g_get_unix_mount_points()
BZ #659528
In registration_data_export_interface(), the object_path is obtained using:
object_path = g_dbus_object_get_object_path (G_DBUS_OBJECT (data->object));
But when exporting an object uniquely, the object_path is not assigned
to the GDBusObject until after all the interfaces are exported.
Therefore, registration_data_export_interface() is trying to export
the interface on the non-unique object path, which can lead to
run-time errors if an object already exists on that path.
Instead, registration_data_export_interface() should be passed the
object_path explicitly, as is done in
g_dbus_object_manager_server_export_unlocked().
Signed-off-by: David Zeuthen <davidz@redhat.com>
Ensure that the output/target stream in a g_output_stream_splice_async()
operation is marked as closed if G_OUTPUT_STREAM_SPLICE_CLOSE_TARGET is
passed to g_output_stream_splice_async(). This removes the possibility of
local FDs being closed twice because the stream's not marked as closed.
This is implemented by calling g_output_stream_close() from within
g_output_stream_splice_async() instead of calling the stream's close_fn()
directly.
Closes: bgo#659324
Otherwise, we could use-after-free the GDBusWorker, if its last-unref
is immediately after _g_dbus_worker_new returns (before the worker thread
does its initial read).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
This member is written in _g_dbus_worker_stop from arbitrary threads, and
read by the worker thread, so it should be accessed atomically.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
We can't safely close the output part of the I/O stream until any
pending write or flush has been completed. In the worst case, this could
lead to an assertion failure in the worker (when the close wins the
race) or not closing the stream at all (when the write wins the race).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
num_writes_pending was a counter, but it only took values 0 or 1, so make
it a boolean: it would never make sense to be trying to write out two
messages at the same time (they'd get interleaved).
Similarly, we can never be writing and flushing at the same time (that'd
mean we were flushing halfway through a message, which would be pointless)
so combine it with flush_pending too, calling the result output_pending.
Also assert that it takes the expected value whenever we change it,
and document the locking discipline used for it, including a subtle
case in write_message_in_idle_cb where it's not obvious at first glance
why we don't need the lock.
(Having the combined boolean at the top of the block of write-related
struct members improves struct packing on 64-bit platforms, by packing
read_num_ancillary_messages and output_pending into one word.)
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add an extra state pointer and an extra GDestroyNotify function
to the 'Chunk' definition... allowing bindings to attach some extra
state to memory chunks (to get memory management correctly from
language bindings).
Bug #589887
The GApplication test case tried to fork() while using GMainLoop,
causing problems. Avoid doing that by splitting the child process into
a separate program and spawning it in the usual way.
https://bugzilla.gnome.org/show_bug.cgi?id=658999
The 'key' variable is no longer valid outside the cycle, owned and
probably already freed by GVariant. This causes apps to segfault
when proxy is constructed and a property on remote d-bus service
changes (actually is invalidated). Looks like a typo anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=659070
* Do not ignore the system default
* Do not exclude the last used being set from the default list
This fixes the default applications dialog in control-center.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
Historically we've added random symbols to the public API with warnings
that they're private; examples are:
glib_gettext(), glib_pgettext()
g_thread_functions_for_glib_use, g_thread_use_default_impl, etc.
And we almost added "GWakeup" to public API just to share between glib and
gio.
This new glib__private__() API exports a hidden vtable, and adds a macro
GLIB_PRIVATE_CALL() that makes it generally convenient to use.
This adds an extremely tiny cost for the double indirection; but it has
the benefit that we don't need to either:
1) compile the code into both glib and gio (like GWakeup), with the
inefficiency that implies.
2) Export a "do not use this" symbol; the serious problem with this is
that someone CAN use it pretty easily. Particularly if we document
it. It's far, far harder to peek into a structure without a public
header file.
https://bugzilla.gnome.org/show_bug.cgi?id=657992
g_thread_gettime() is an undocumented public function pointer that
points to a function that returns the monotonic time in nanoseconds.
g_get_monotonic_time() does the same in microseconds, so it can be used
instead.
GLib had one internal user in GFileMonitor that only cared about
millisecond accuracy; it has been ported to g_get_monotonic_time().
In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.
https://bugzilla.gnome.org/show_bug.cgi?id=616754
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
Non-technical users won't know that "stating" refers to stat(2), so we
just use "error when getting information" now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
When g_settings_apply() is called on a delayed settings backend and
there is a D-Bus error when communicating with dconf-service, recent
versions of the dconf GSettingsBackend call a function in GLib that
improperly delivered the signal directly instead of using
g_main_context_invoke().
This patch fixes this function to route in the same way as the others so
that the signal is dispatched in the proper GMainContext.
- getmntinfo can take struct statfs or statvfs depending on the
OS. Use getvfsstat and if not found getfsstat instead. Idea from
Dan Winship.
- g_local_file_query_filesystem_info(): use statvfs.f_fstypename
if available
https://bugzilla.gnome.org/show_bug.cgi?id=617949
The threaded tests are using the default main context in the worker
thread, but were not g_main_context_acquire()ing it first, which meant
that g_tls_interaction_invoke_ask_password() in the main thread would
sometimes succeed in acquiring it itself and thus performing the
operation in the wrong thread. Fix that.
Also, we can't unref the loop from the worker thread, because the main
thread isn't holding a reference on it, and so it might end up being
destroyed while that thread is still inside g_main_loop_quit().
(which shouldn't ever have been part of the API. Grr.)
Solaris /etc/services doesn't even have "http", which was causing
tests/network-address to fail...
On Solaris, getsockname() on an unconnected socket gives an addrlen of
0 and doesn't set the sockaddr. So use the SO_DOMAIN sockopt to find
the socket family in that case. (SO_DOMAIN doesn't exist everywhere,
so we can't use it unconditionally. Also, we have to only use it if
getsockname() fails, since SO_DOMAIN returns a bogus value for
accept()ed sockets on both Linux and Solaris...)
Also, link libgio to -lresolv explicitly, rather than depending on
getting it implicitly via the libasyncns build (which should
eventually be going away).
https://bugzilla.gnome.org/show_bug.cgi?id=645336
* Add 'invoke' style method, which can be used to call an interaction
from any thread. The interaction will be run in the appropriate
#GMainContext
* Sync methods can be called whether main loop is running or not.
* Derived classes can choose to implement only sync or async
interaction method, and the invoke method will fill in the blanks.
* Documentation for the above.
* Tests for the above.
https://bugzilla.gnome.org/show_bug.cgi?id=657567
g_desktop_app_info_set_as_default_for_type() and
g_desktop_app_info_set_as_last_used_for_type () require the
application's ID, but depending on how the GAppInfo was created,
we might not be have one, and would thus silently fail to set
the default application, or last used application.
https://bugzilla.gnome.org/show_bug.cgi?id=657445
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
The docs for g_socket_set_timeout() claimed that if an async operation
timed out, the GIOCondition passed to the source callback would be
G_IO_IN or G_IO_OUT (thus prompting the caller to call
g_socket_receive/send and get a G_IO_ERROR_TIMED_OUT), but in fact it
ended up being 0, and gio/tests/socket.c was erroneously testing for
that instead of the correct value. Fix this.
* Load modules from paths listed in GIO_EXTRA_MODULES environment
variable first.
* Ignore duplicate modules based on module basename.
* Add the concept of GIOModuleScope which allows other callers to
skip duplicate loaded modules, or block specific modules based on
basename.
* Document behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=656914
* Add cancellable argument to g_tls_interaction_ask_password
and g_tls_interaction_ask_password_async.
* This is API breakage, but this API has not yet been released
in a stable release (and very unlikely used yet).
* Since we're breaking unreleased API, expand amount of padding
on GTlsInteractionClass because we're going to need it.
https://bugzilla.gnome.org/show_bug.cgi?id=656443
Change the hardcoded /usr/bin/python shebag from gdbus-codegen.in into
@PYTHON@. Is used in Makefile.am to use detected python binary.
$(AM_V_GEN) sed -e 's,@libdir\@,$(libdir),' -e 's,@PYTHON\@,$(PYTHON),'
$< > $@.tmp && mv $@.tmp $@
Signed-off-by: Ionut Biru <ibiru@archlinux.org>
https://bugzilla.gnome.org/show_bug.cgi?id=657274
Rework property getters to use a vfunc so we can take the fast path
and avoid allocating memory for both the skeleton and the proxy
cases. This requires some special case because of how GVariant expects
you to free memory in some cases, see #657100. Add test cases for
this.
Document the _get_ functions as not being thread-safe and also
generate _dup_ C getters (which are thread-safe).
Mark all the generated _get_, _dup_ and _set_ as (skip) as non-C
languages should just use GObject properties and not the (socalled)
"C binding".
Signed-off-by: David Zeuthen <davidz@redhat.com>
The main rationale for adding it was to avoid having gnome-shell
mmap'ing /etc/localtime once a second. However, we can just as easily
run inotify there, and given no one else was clamoring for a way to
detect when the time zone changes, I don't see a need for public API
here - at least not yet.
In the bigger picture, I just don't believe that the vast majority of
applications are going to go out of their way to instantiate and keep
around a random GTimeZoneMonitor class. And if they do, it's has the
side effect that for other bits of code in the process, local GDateTime
instances may start varying again!
So, if code can't rely on local GDateTime instances being in a
consistent state anyways, let's just do that always. The
documentation now says that this is the case. Applications have
always been able to work in a consistent local time zone by
instantiating a zone and then using it for GDateTime constructors.
We fix the "gnome-shell stats /etc/localtime once a second" issue by
using timerfd (in glib) and inotify (in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=655129
* Update documentation to note that GCancellable can be used
concurrently by multiple operations.
* Add documentation to g_cancellable_reset that behavior is
undefined if called from within cancelled handler.
* Add test for multiple concurrent operations using the same
cancellable.
https://bugzilla.gnome.org/show_bug.cgi?id=656387
