It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.
Add an explicit assert here to quiet up static analysis.
See the bug for more discussion.
Coverity CID: 1159477
https://bugzilla.gnome.org/show_bug.cgi?id=730296
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
gtk-doc doesn’t make the return type clear, because these are macros
rather than inline functions, so people often have to guess at the
return type (or look it up from g_signal_connect_closure(), but that’s
hard work).
Make it clear that the return type for handler IDs is gulong. While
there, fix the capitalisation of ‘id’ to ‘ID’ in a few places.
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
This is almost always what you want, because if you're using this you
want to know if any "custom code" (i.e. not the default class closure)
is going to be run if you emit this signal.
I looked at all the existing uses of this and they were all broken in the
presence of g_signal_override_class_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=754986
It’s quite common to see naked g_signal_connect() calls without a paired
g_signal_handler_disconnect(). This is commonly a bug which could lead
to uses of the callback user data after it’s been freed.
Document the best practices for avoiding this kind of bug by properly
disconnecting all signal handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Add a global lookup table for signal handlers. We already give
them a unique ID, so there is no good reason to pay for
non-constant lookups when disconnecting handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=737009
Used for the commonly used case (in signal emission) where we
initialize and set a GValue for an instance
Includes a fast-path for GObject
Overall makes it 6 times faster than the previous combination
of g_value_init + g_value_set_instance
Makes signal emission around 10% faster
https://bugzilla.gnome.org/show_bug.cgi?id=731950
- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=728983
We previously hold a lock in the loop that collects the arguments for
g_signal_emit(), which we drop before calling into the argument
collection functions and reacquire again at the bottom of the loop (ie:
one release/acquire pair for each argument collected). To make matters
worse, the lock is just released again after the loop.
Presumably that was done to protect the access to the parameter array,
but it's pretty unlikely that this is needed because the only way it
changes is if the signal is unloaded. That only happens when unloading
types which is quite unlikely to happen while we are emitting on an
instance of that type (and, as an aside, never happens anymore anyway).
If we move the unlock below the loop up above it and remove the
acquire/release pair from the loop, we improve performance in the new
arg-collecting performance tests by ~15% (more like ~18% in the case
where we only emit to one handler -- where argument collection dominates
more).
https://bugzilla.gnome.org/show_bug.cgi?id=694380
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
When looking up signals by name (to connect, for example) and the named
signal cannot be found on the given instance, report the type of the
instance.
This is quite a lot more useful as a diagnostic message than only a
memory address.
https://bugzilla.gnome.org/show_bug.cgi?id=694350
We need to keep a reference to the handler in the fast path, just like
in the slow path, otherwise if another thread disconnects the handler
we may destroy the closure while we're using it without the lock held.
We also move the freeing of the instance to after the emission is totally
done as the handler_unref_R (and the tracepoint) reference it.
https://bugzilla.gnome.org/show_bug.cgi?id=694253
handler_ref and handler_unref_R are always called with the signal
lock held. This is obvious for handler_unref_R as it even sometimes
drops this lock, and can be verified quickly for handler_ref by looking
at all call sites.
This improves the performace about 6% on the emit-handled and the
emit-handled-generic tests.
https://bugzilla.gnome.org/show_bug.cgi?id=694253
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
Modify gsignal to automatically disconnect a GClosure that becomes
invalid (in the g_closure_invalidate() sense).
Previously, when g_signal_connect_object() was used with a GObject as
the user_data and that object was destroyed, the handler would no longer
be called but the signal handler was itself was not disconnected (ie:
the bookkeeping data was kept around).
The main effect of this patch is that these signal handlers will now
be automatically disconnected (and fully freed).
The documentation for g_signal_connect_object() has anticipated this
change for over 10 years and has advised the following workaround when
disconnecting signal handlers connected with g_signal_connect_object():
if (g_signal_handler_is_connected (instance, id))
g_signal_handler_disconnect (instance, id);
If your code follows this practice then it will continue to work.
If your code never disconnects the signal handler then it was wasting
memory before (and this commit fixes that).
If your code unconditionally disconnects the signal handler then you
will start to see (harmless) g_critical() warnings about this and you
should fix them.
https://bugzilla.gnome.org/show_bug.cgi?id=118536
If the optimization is used for only having one closure handling a
signal emission, then hooks will not be run, so it should be disabled
when an emission hook is added.
https://bugzilla.gnome.org/show_bug.cgi?id=671918
The trace of the signal emission of the was calculating the instance
type after the instance was unrefed. Fix this by keeping the instance type around.
