Ryan accidentally committed some debugging code a long time ago,
causing this file to always use futex emulation even when real futex
support was available. I noticed this a while later and pointed it out
to him, and assumed he was going to fix it, but I guess he assumed I
was going to fix it, and then neither of us did...
https://bugzilla.gnome.org/show_bug.cgi?id=699500
Higher order languages with garbage collection can have issues releasing
a binding, as they do not control the last reference being dropped on
the binding, source, or target instances.
https://bugzilla.gnome.org/show_bug.cgi?id=698018
The GError should be initialized to NULL, otherwise we'll
"pile up" errors, then try to free an uninitialized pointer.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=699493
This ancient code was attempting to cope with (unknown) systems whose
malloc() prototype was incompatible with the standard. This test was
fragile; it would break if the build environment provided -Wall in
CFLAGS.
Now that it's 2013, let's assume that target systems have a sane
malloc(). If someone complains, we can revisit this.
https://bugzilla.gnome.org/698716
There is some code in the wild (like in gnome-session) that does this
from its custom _constructor() implementation:
{
GObject *obj;
obj = ((chain up));
if (!object_is_viable (obj))
{
g_object_unref (obj);
return NULL;
}
else
return obj;
}
This has never been a valid use of GObject and this code has always
caused memory to be leaked[1] by growing the construction_objects list.
The ability to legitimately return NULL from a constructor was exactly
the reason that we created GInitable, in fact.
That doesn't change the fact that the g_object_new() rewrite will crash
in this case, so instead of doing that, let's emit a critical and avoid
the crash. This will allow people to upgrade their GLib without also
upgrading their gnome-session. Meanwhile, people can fix their broken
code.
[1] not in the strictest sense of the word, because it's still reachable
Not all systems have /usr/bin/true. Some have it in /bin/true.
Instead of trying to guess a hardcoded path to find it, let
g_app_info_create_from_commandline() internally search PATH
to find the program.
https://bugzilla.gnome.org/show_bug.cgi?id=698655
Make a number of improvements to g_object_new():
- instead of looking up the GParamSpec for the named property once in
g_object_new() (in order to collect) and then again in g_object_newv
(when actually setting the property), g_object_new_internal() is a
new function that takes the GParamSpec on the interface to avoid the
second lookup
- in the case that ->constructor() is not set, we need not waste time
creating an array of GObjectConstructParam to pass in. Just directly
iterate the list of parameters, calling set_property() on each.
- instead of playing with linked lists to keep track of the construct
properties, realise that the number of construct properties that we
will set is exactly equal to the length of the construct_properties
list on GObjectClass and the only thing that may change is where the
value comes from (in the case that it was passed in)
This assumption was already implicit in the existing code and can be
seen from the sizing of the array used to hold the construct
properties, but it wasn't taken advantage of to make things simpler.
- instead of allocating and filling a separate array of the
non-construct properties just re-iterate the passed-in list and set
all properties that were not marked G_PARAM_CONSTRUCT (since the ones
that were construct params were already used during construction)
- use the new g_param_spec_get_default_value() API instead of
allocating and setting the GValue for each construct property that
wasn't passed from the user
Because we are now iterating the linked list of properties in-order we
need to append to that list during class initialising instead of
prepending.
These changes show a very small improvement on the simple-construction
performance testcase (probably just noise) and they improve the
complex-construction case by ~30%.
Thanks to Alex Larsson for reviews and fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
The way of getting the default value out of a GParamSpec is to allocate
a GValue, initialise it, then call g_param_spec_set_default() to set the
default value into that GValue.
This is exactly how we handle setting the default value for all of the
construct properties that were not explicitly passed to g_object_new().
Instead of doing the alloc/init/store on all construct properties on
every call to g_object_new(), we can cache those GValues in the private
data of the GParamSpec itself and reuse them.
This patch does not actually make that change to g_object_new() yet, but
it adds the API to GParamSpec so that a future patch to GObject can make
the change.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
Since instance private data is now always at a constant offset to the
instance pointer, we can add an accessor for it that doesn't also
require an instance.
The idea is that classes can call this from their class_init and store
it in a file-scoped static variable and use that to find their private
data on instances very quickly, without a priv pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
This partially reverts commit ce0022933c.
It used to be safe to use g_spawn_sync() from processes that had their
own SIGCHLD handler because it simply called wait(). When it was
changed to depend on the GLib child watching infrastructure this meant
that GLib had to own the SIGCHLD handler.
This caused hangs in at least Pidgin.
The patch contained two other improvements to the child watch code which
we want to keep, so only revert the changes to gspawn itself.
https://bugzilla.gnome.org/show_bug.cgi?id=698081
GUnixSocketAddress has some very strange logic for interpreting its
construct paramters. This logic behaves differently in these two cases:
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"abstract", FALSE,
"address-type", ...,
NULL);
and
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"address-type", ...,
NULL);
even though the default value for "abstract" is already FALSE.
Change the way the code works so that it is not sensitive to people
merely setting a property to its default value.
https://bugzilla.gnome.org/show_bug.cgi?id=698686
This reverts commit ddb0ce1421.
Colin's smoke testing has found issues in at least gjs and
gnome-settings-daemon. We'll need to see if we can address those.
GObject has previously allowed installing properties after class_init
has finished running. This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.
Prevent this from happening. Require that all properties are installed by
the time class_init has finished.
Complaints go to this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=698614
Classically, a GTypeInstance has had the following layout:
[[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]
where TypeB is a subclass of TypeA which is a GObject. Both TypeA and
TypeB use pivate data.
The main problem with this approach is that the offset between a pointer
to an instance of TypeA and the TypeAPrivate is not constant: it changes
depending on the depth of derivation and the size of the instance
structures of the derived types. For example, changing the size of the
TypeB structure in the above example would push the TypeAPrivate further
along.
This complicates the implementation of g_type_instance_get_private().
In particular, during object construction when the class pointer to the
'complete type' of the object is not yet stored in the header of the
GTypeInstance, we need a lookup table in order to be able to implement
g_type_instance_get_private() accurately.
We can avoid this problem by storing the private data before the
structures, in reverse order, like so:
[TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]
Now the distance between TypeA and TypeAPrivate depends only on the size
of GObject and GTypeInstance, which are static. Even in the case of
TypeB, the distance is not statically known but can be determined at
runtime and is constant (because we will know the size of TypeAPrivate
by the time we initialise TypeB and it won't change).
This approach requires a slighty dirty trick: allocating extra memory
_before_ the pointer we return from g_type_create_instance(). The main
problem with this is that it will cause valgrind to behave very badly,
reporting almost everything as "possibly lost".
We can correct for this by including a few valgrind client requests in
order to inform it that the start of the GTypeInstance should be
considered a block of memory and that pointers to it should mean that
this block is reachable. In order to make the private data reachable,
we also declare it as a block and include an extra pointer from the end
of the primary block pointing back at it. All of this is only done if
we are running under Valgrind.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
All experienced GLib hackers know that G_SLICE=always-malloc is
absolutely essential when valgrinding but many users of GLib don't know
about this and get hit pretty hard when valgrinding their programs.
When initialising gslice, add a check to see if we are running under
valgrind and disable ourselves if we are.
We only do the check in the case that G_SLICE= was not specified in the
environment, so setting it to an empty string will prevent this default
behaviour.
I considered modifying gslice to use the VALGRIND_MALLOCLIKE_BLOCK
client request in all cases in order to just mark the blocks properly
but these calls are not free and gslice is pretty hyper-optimised. It's
easier to just disable gslice completely and this way we only have to do
one check during startup. It's also theoretically possible that someone
might want to use valgrind to debug gslice, in which case the extra
annotations would probably cause quite a lot of difficulty.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
This is a BSD-licenced header file that is designed to be copy-pasted
into programs. It will allow us to detect if we are running under
Valgrind and send "client requests" to it.
We will use this for a couple of reasons in upcoming patches.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
This function takes a GIcon, serialises it and sets the resulting
GVariant as the "icon" attribute on the menu item. We will need to add
a patch to Gtk to actually consume this icon.
Also add G_MENU_ATTRIBUTE_ICON.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Add support for serialising a GIcon to a GVariant and deserialising the
result back to a GIcon.
This solves a number of problems suffered by the existing to_string()
API, primarily these:
- not forcing the icon to be a utf8 string means that we can
efficiently encode a PNG (ie: just give the array of bytes)
- there is no need to ensure that proper types are loaded before using
the deserialisation interface. 'Foreign' icon types will probably
emit a serialised format the deserialises to a GBytesIcon.
We additionally clearly document what is required for being a consumer
or implementation of #GIcon.
Further patches will be required to GdkPixbuf and GVfsIcon to bring
their implementations in line with the new rules (essentially: introduce
implementations of the new serialize() API).
https://bugzilla.gnome.org/show_bug.cgi?id=688820
GBytesIcon is an icon that has a GBytes inside of it where the GBytes
contains some sort of encoded image in a widely-recognised file format.
Ideally this will be a PNG.
It implements GLoadableIcon, so GTK will already understand how to use
it, but we will add another patch there to make things more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Split out the 'simple string format' cases of URIs, file paths and
themed icons to a separate function.
This function will be shared by g_icon_deserialize().
https://bugzilla.gnome.org/show_bug.cgi?id=688820
