In the event that a GSettings object is being destroyed just as a change
signal is being delivered, the destroying thread will race with the
dconf worker thread for acquiring the lock on the GSettingsBackend.
If the signalling thread gets there first then the destroying thread
will block on the lock. The signalling thread adds a reference to the
GSettings object that is being destroyed and releases the lock. The
idea is that this should prevent the GSettings object from being
destroyed and thus maintain its entry in the list. Unfortunately, the
weak reference notify function is already running and as soon as we
release the lock, the list entry is removed.
The signalling thread crashes.
This bug is indicative of a serious problem encountered in many
situations where GObject instances are touched from multiple threads.
Ideally, we will move to a place where g_object_ref() is not called at
all on the GSettings object from the dconf worker thread and instead, a
dispatch will be done without holding a reference (similar to how
GAppInfoMonitor presently works). This would also prevent the
unfortunate case of someone dropping what they assume to be the last
reference on a GSettings object, only to have an already-pending signal
delivered once they return to the mainloop, crashing their program.
Making this change for GSettings (with multiple instances per thread,
the possibility of multiple backends and each instance being interested
in different events) is going to be extremely non-trivial, so it's not a
change that makes sense at this point in the cycle.
For now, we can do a relatively small and isolated tweak so that we
never access the list except under a lock. We still perform the bad
pattern of acquiring a ref in a foreign thread which means that we still
risk delivering a signal to a GSettings object that the user has assumed
is dead (unless they explicitly disconnect their signal handler). This
is a problem that we already had, however.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
Change the order of the arguments on the (internal) keys_changed callback in
GSettingsListenerVTable.
This means that all functions in the table now fit the following signature:
void (* f) (GObject *target,
GSettingsBackend *backend,
const gchar *name_or_path,
gpointer origin_tag,
const gchar * const *names);
allowing the possibility of arguments ignored at the end.
This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
making it a bit less generic.
So far, this should be a straight refactor.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
The _finish functions for GUnixVolume _mount and _eject functions were
never implemented, having been simply stubbed out as 'return TRUE;'.
Implement them.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
The existing code is buggy and now that we have GSubprocess, we should just use
it instead, allowing for some substantial reduction in complexity.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
As of e6af432, g_content_type_get_symbolic_icon() returns non-symbolic
fallbacks. Thus, we can't append another symbolic icon to the fallbacks.
The special case was a bit of a hack anyway. It was only applied to
themed icons and there was no generic fallback for mime types that are
not folders.
https://bugzilla.gnome.org/show_bug.cgi?id=726046
We need to have these in BUILT_SOURCES so that 'make' knows to generate them
before attempting to compile other .c files in the same directory (since some
of these files include the header).
Should fix up remaining issues about partial versions of this file being
included under parallel builds.
https://bugzilla.gnome.org/show_bug.cgi?id=725891
This means that the test can't build on Windows (and we do want it there).
This will be properly resolved with bug 725266, but let's not block the
build before then.
https://bugzilla.gnome.org/show_bug.cgi?id=724859
Add a test for GSubprocess to test setting, unsetting and inheritance of
environment variables. Use communicate() to give it a bit more of a
workout as well.
https://bugzilla.gnome.org/show_bug.cgi?id=725651
On the splice for stdout or stderr completing, GSubprocess calls
_slice_finish() to collect the result.
We assume that a zero return value here means failure, but in fact this
function returns a gssize -- the number of bytes transferred, or -1 for
an error.
This causes GSubprocess to mistakenly think that it has an error when it
actually just has an empty buffer (as would be the case when collecting
stderr from a successful command).
Check for -1 instead of FALSE to detect the error.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
Add the basename from the first component of the Exec line to the list of
strings to search for via g_desktop_app_info_search().
We treat Exec as a fairly strong match -- just below the visible name.
Add a testcase to make sure everything is working OK.
https://bugzilla.gnome.org/show_bug.cgi?id=725023
For now, we are mainly interested in G_MARKUP_TREAT_CDATA_AS_TEXT.
This commit makes markup-parse look for expected output files with
the extension .cdata-as-text in addition to .expected, and compares
the output of parsing with G_MARKUP_TREAT_CDATA_AS_TEXT against
them. markup-parse --cdata-as-text foo.gmarkup can be used to produce
such expected output.
Simplify our tracking of issued source id integers and fix some bugs.
Previously the source's id was remove from the 'used' table from
source_remove_from_context() which was also called if the source
priority was changed (in which case it would never be added back to the
table). The source id could be reissued in that case.
In the new approach, we just always keep a hash table of sources, by
source id. This simplifies the logic and will also allow us to improve
performance of g_main_context_find_source_by_id() which is called in some
fairly common cases, such as g_source_remove(). These improvements will be in
the following commits.
https://bugzilla.gnome.org/show_bug.cgi?id=724839
88182d375e caught this issue in
g_async_queue_timed_pop() but failed to fix the same bug in the _unlocked()
variant.
This is only a problem on 32bit systems. On 64bit systems, the tv_sec
in a timeval is already 64 bits, so no overflow occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=722604
Visual C++ is quite zealous about checking against the types used in the
initializing of array of structures, even up to Visual C++ 2013. Fix this
by splitting up the initializing steps.
https://bugzilla.gnome.org/show_bug.cgi?id=724609
