==24706== 52 bytes in 1 blocks are definitely lost in loss record 7,248 of 13,092
==24706== at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==24706== by 0x70E9F5F: standard_malloc (gmem.c:85)
==24706== by 0x70E9FE8: g_malloc (gmem.c:159)
==24706== by 0x71018EC: g_slice_alloc (gslice.c:1003)
==24706== by 0x710192B: g_slice_alloc0 (gslice.c:1029)
==24706== by 0x7068526: g_type_create_instance (gtype.c:1872)
==24706== by 0x705067B: g_object_constructor (gobject.c:1835)
==24706== by 0x704FE47: g_object_newv (gobject.c:1699)
==24706== by 0x7050612: g_object_new_valist (gobject.c:1816)
==24706== by 0x704F894: g_object_new (gobject.c:1531)
==24706== by 0x6F0F2F0: g_inet_address_new_from_bytes (ginetaddress.c:459)
==24706== by 0x6F5D703: remove_network (gnetworkmonitornetlink.c:256)
==24706== by 0x6F5DD80: read_netlink_messages (gnetworkmonitornetlink.c:386)
==24706== by 0x6F2D5CA: socket_source_dispatch (gsocket.c:2505)
==24706== by 0x70E1D45: g_main_dispatch (gmain.c:2513)
==24706== by 0x70E2A06: g_main_context_dispatch (gmain.c:3050)
==24706== by 0x70E2BE9: g_main_context_iterate (gmain.c:3121)
==24706== by 0x70E2CAD: g_main_context_iteration (gmain.c:3182)
==24706== by 0x6F60A05: g_application_run (gapplication.c:1599)
==24706== by 0x42D011: main (ephy-main.c:472)
https://bugzilla.gnome.org/show_bug.cgi?id=667098
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
This can be used for debugging, or for progress UIs ("Connecting to
example.com..."), or to do low-level tweaking on the connection at
various points in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=665805
Previously it was more or less assumed that GSocketConnections were
always connected, although this was not enforced. Make it explicit
that they don't need to be, and add methods to connect them, and
simplify GSocketClient by using those methods.
https://bugzilla.gnome.org/show_bug.cgi?id=665805
41e5ba86a7 introduced some changes to the
property flags of GAction. These changes were not a reflection of the
actual interface of GAction but were necessary due to GObject being
overly-sensitive to flag changes on property overrides.
Now that the GObject bug is fixed, we can restore the GAction flags to
their correct values.
https://bugzilla.gnome.org/show_bug.cgi?id=666615
It happens that one wants to customize settings for plugins or
shell extensions, that installing schemas in nonstandard locations.
This patch adds the --schemadir option to gsettings, and ensure
that the appropriate schema is found.
https://bugzilla.gnome.org/show_bug.cgi?id=666415
This interfaceifies the extra functions that were on GDBusActionGroup
for dealing with platform data.
The two main benefits of doing this:
- no longer have to do a silly song and dance in GApplication to avoid
calling GDBusActionGroup API from non-dbus-aware code
- the interface can be reused by the action group exporter to avoid
ugly and unbindable hook callbacks
https://bugzilla.gnome.org/show_bug.cgi?id=665737
Now that we're a GActionMap the story about propagating signals from our
(now-constant) internal action group is vastly simplified. If someone
calls g_application_set_action_group() then signals will stop working --
but this function is deprecated and they never worked before, so no big
loss there.
https://bugzilla.gnome.org/show_bug.cgi?id=643736
We provide a mechanism by which a 'platform' (eg: Gtk) can register some
hook functions to be called to collect platform-data at the point of
sending an outgoing action activation request and also to inform the
platform of this data on incoming requests (before and after dispatching
the actual request).
This can be used for forwarding timestamp and startup-notification
information (as is presently done in GApplication) but the before/after
hook could also be used for acquiring/releasing the Gdk lock or other
similar things.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
Various places in the code were assuming that the hash table was always
available. Fix this, and also avoid leaking strings now that the hash
table may be NULL.
Based on a patch by Simon McVittie, bug 666167
g_main_loop_quit() only quits mainloops that are currently running --
not ones that may run in the future. The way the gdbus-threading tests
are written can possibly result in a call to g_main_loop_quit() before
g_main_loop_run() has started.
The mainloops aren't actually used for anything other than signalling
the completion of the threads, so just use g_thread_join() for that.
https://bugzilla.gnome.org/show_bug.cgi?id=666129
When trying to compile glib master on a RHEL 6.2 system, it fails with:
make[4]: Entering directory `/home/teuf/gnome/src/glib/gio'
CC libgio_2_0_la-gnetworkmonitornetlink.lo
In file included from gnetworkmonitornetlink.c:25:
/usr/include/linux/netlink.h:35: error: expected specifier-qualifier-list before 'sa_family_t'
gnetworkmonitornetlink.c: In function 'g_network_monitor_netlink_initable_init':
gnetworkmonitornetlink.c:99: error: 'struct sockaddr_nl' has no member named 'nl_family'
gnetworkmonitornetlink.c💯 error: 'struct sockaddr_nl' has no member named 'nl_pid'
gnetworkmonitornetlink.c💯 error: 'struct sockaddr_nl' has no member named 'nl_pad'
gnetworkmonitornetlink.c:101: error: 'struct sockaddr_nl' has no member named 'nl_groups'
make[4]: *** [libgio_2_0_la-gnetworkmonitornetlink.lo] Error 1
sa_family_t is defined in sys/socket.h, this commit makes sure this header is included before netlink.h
This fixes bgo bug #666001
GDBusConnection recently changed to dispatching its GDestroyNotify calls
from an idle instead of on-the-spot. Under the previous regime, we
would destroy-notify the action group export of a GtkApplicationWindow
at the point it was removed from the application (ie: slightly before
being disposed).
With the destroy notify now deferred to an idle, the window has already
been disposed, so the signal handlers have already been disconnected.
Avoid the problem by dropping our use of signal IDs and just do
g_signal_handlers_disconnect_by_func(), which doesn't complain if there
is no connection.
