There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Ok, this function was just an awful mess before. Now the problem
domain is not trivial, and I won't claim this new code is *beautiful*,
but it should fix the bug at hand, and be somewhat less prone to
failure for the next person who tries to modify it. There's only one
unref call for each object now.
https://bugzilla.gnome.org/show_bug.cgi?id=692408
gio's glib-mkenums call needs to get gnetworking.h out of $(builddir),
not $(srcdir). Fix/simplify it by using $(filter) on $^ and letting
make find everything.
Also add -Wno-portability to AM_INIT_AUTOMAKE in configure.ac, so that
it doesn't warn about this (or about the gmake-specific features we
were already using in gio/tests/)
https://bugzilla.gnome.org/show_bug.cgi?id=691866
Use the same code GSocket does, to try SOCK_CLOEXEC first, and then
fall back to FD_CLOEXEC if it fails. (And fix that code to not call
fcntl if SOCK_CLOEXEC worked.)
https://bugzilla.gnome.org/show_bug.cgi?id=692332
When an error occurs while reading the file input stream in
g_file_load_contents (e.g. because the operation was cancelled), the
code is correctly calling g_task_return_error(), but in the callback
from the close operation, g_task_return_boolean() will be called again.
Code that cleans up its state in the async callback will then be called
twice, leading to invalid memory access.
https://bugzilla.gnome.org/show_bug.cgi?id=692202
The point of g_source_set_closure() is getting memory management right,
including handling closures disappearing from the outside (for example
because a runtime they refer to is being shutdown). This means that
sources with an associated closure should remove themselves from the
main loop and free memory when the closure is invalidated.
https://bugzilla.gnome.org/show_bug.cgi?id=692034
Declare explicit support for monitor NFS from the fam file monitoring
backend. This will cause it to be preferred for monitoring on NFS, if
it is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Add a pair of new extension points: 'gio-nfs-file-monitor' and
'gio-nfs-directory-monitor'.
Add a check to GLocalFile when creating a file monitor. If the
requested file is in the user's home directory and the user has an NFS
home directory then attempt to use an implementation of one of the new
extension points. If we don't have any implementations then fall back
to the normal "local" monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Get rid of the complicated default module detection code in
GLocalFileMonitor and GLocalDirectoryMonitor and use the new
_gio_module_get_default_type() function instead.
This change also adds the ability to override the default file monitor
via the GIO_USE_FILE_MONITOR environment variable in the same way as can
be done for GIO_USE_VFS.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
_gio_module_get_default() is a very convenient function for modules
implementing a singleton -- it finds the default module by priority
subject to override by a given environment variable name, instantiates
it, and caches the instance for future calls. It also has the ability
to query instances for being 'active' using a callback.
It doesn't work very well for non-singletons (like file monitors).
Add a new function _gio_module_get_default_type() that skips the
instantiation, returning the GType instead. As a replacement for the
'active' callback, a vtable offset can be given for a virtual function
to use to query if a particular backend is supported.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
We no longer need entries to generate the .def files in the property sheets
as we are now doing __declspec (dllexport) to export all the needed
symbols. So, purge these items from the property sheets since they are no
longer used.
We should also stop using gthread/gthread.def file as well, since we
also use __declspec (dllexport) for the two (deprecated) functions there
since commit f8756694.
This should also silence some linker warnings in x64 builds.
Also get rid of the references to the .symbols files in the
.vcxproj.filters(in) in the various Visual C++ 2010 projects
GVariant has the concept of fixed-sized types (ie: types for which all
values of the type will have the same size). Examples are booleans,
integers, doubles, etc. Tuples containing only these types are also
fixed size.
When GVariant is trying to deal with a fixed-sized value for which it
doesn't have a sufficient backing store (eg: the case where a
fixed-sized value was created with g_variant_new_data() with an
incorrect number of bytes) it denotes this by setting the size of the
value to the correct fixed size but using a NULL data pointer.
This is well-documented in several code comments and also in the public
API documentation for g_variant_get_data() which describes the situation
number which NULL could be returned.
The decision to deal with this case in this way was changed at the last
minute around the time that GVariant was merged -- originally we had an
elaborate setup involving allocating an internal buffer of sufficient
size to be shared between all invalid values.
Unfortunately, when making this change a small detail was missed.
gvs_tuple_get_child() (the function responsible for deserialising
tuples) was updated to properly check for this case (and it contains a
comment about why it must). gvs_tuple_is_normal() (the function
responsible for verifying if a tuple is in normal form) was not.
We add the check now.
Note that this problem does not exist with any other container type
because tuples are the only container capable of being fixed-sized. All
other container types (arrays, maybes, variants) can contain a variable
number of items or items of variable types (note: we consider dictionary
entries to be two-tuples). The code for validating non-container values
also contains a check for the case of NULL data.
The problem also does not occur in the only other function dealing with
serialised tuples: gvs_tuple_n_children(). Whereas other container
types would have to inspect the serialised data to determine the number
of children, for tuples it can be determined directly from the type.
We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
pcre, xdgmime, etc.) that build convenience libraries that are then
included into libglib and libgio. The files in these directories need
to be built with the same visibility policy as the files in the first
level directories, so add CFLAGS for them all.
This wasn't a problem when the visibility flags were set directly in
CFLAGS but then we had to deal with some modules that we built that we
explicitly wanted to export symbols from.
For now, we can keep things the way they are because it's less hacky and
although it's a theoretical hazard to forget these CFLAGS, we rarely add
new subdirectories to the build.
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
This is the bug that has been causing segfaults and criticals when accel
keys are used to close windows via GtkUIManager.
The main cause of this problem was a mistake made in the original patch
when modifying the handler_lookup() to take the extra 'closure'
parameter. The original check used was:
if (handler->sequential_number == handler_id ||
(closure && handler->closure == closure))
It was called to find a particular closure like so:
handler_lookup (instance, 0, closure, &signal_id);
The problem is that the check will return if either the signal ID or
closure matches (if a closure was given). The calling code assumes 0 to
be an invalid signal ID which will match no handlers, but unfortunately
the rest of gsignal code uses this to denote a signal that has already
been disconnected. The result is that this function was searching for a
matching closure _or_ the first already-disconnected handler. When it
found the already-disconnected handler, we'd get criticals and crashes.
The condition has been corrected; it now ignores the handler_id
parameter if the closure parameter is non-NULL.
While we're in here, change the lifecycle of the invalidation notify to
be easier to understand.
Before, the notify was removed when the last reference on the handler
dropped. This could happen in very many situations; often at the end of
an emission. Instead, we now tie the registration of the notifier to
the lifecycle of the signal connection. When the signal is disconnected
we remove the notification, even if other references are held (eg:
because it is currently being dispatched).
https://bugzilla.gnome.org/show_bug.cgi?id=690118
