Transparent access to a weak pointer from the thread performing the
weak -> strong conversion is incompatible with thread-safety: that
thread will have to do something special. This is GNOME#548954.
https://bugzilla.gnome.org/show_bug.cgi?id=548954
==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
-Make the contents of the preconfigured config.h.win32(.in) more like the
contents of config.h.in
-Correct the sizing of void* on x64 platforms (which should be 8, unlike
4 on x86-32 platforms)
fix enables g_strescape() and g_strcompress() to handle '\v' along with other
special characters - '\b', '\f', '\n', '\r', '\t', '\'.
https://bugzilla.gnome.org/show_bug.cgi?id=664830
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
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
Link to zlib1.lib for release builds and zlib1d.lib for debug builds-
this is to be consistent across the board for the GTK+ stack (and many
other opensource code linking to the ZLib DLL on Windows)
When removing an item from the list, check the next one's my_owner,
and fix it accordingly. And take this case into account when last
of the list is deleted.
Also, assign NULL to 'my_owner' in g_thread_xp_WakeConditionVariable.
We were previously preventing implementations of an interface from
specifying G_PARAM_CONSTRUCT for a property of that interface if the
interface didn't specify it itself (or was readonly).
This is something that should only interest the implementation, so we
remove this restriction.
This allows 6 new possible override scenarios:
- writable -> writable/construct
- writable -> readwrite/construct
- readwrite -> readwrite/construct
- writable/construct-only -> writable/construct
- writable/construct-only -> readwrite/construct
- readwrite/construct-only -> readwrite/construct
and we update the testcase to reflect this.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Add a testcase to check all possibilities for overriding a property
specified on an interface from an implementation of that interface,
changing the type and flags.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Change the order of the checks so that we hear about the 'biggest'
problem first. Also, stop reporting problems after we report the first
one for a particular property.
Add some comments.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
The property override typecheck was meant to enforce the type on the
overriding property being exactly equal to the type on the interface
property. Instead, g_type_is_a() was incorrectly used.
We could try to enforce equality, but if a property is read-only then it
should be possible for the implementation to type the property with any
subtype of the type specified on the interface (because returning a more
specific type will still satisfy the interface). Likewise, if the
property is write-only then it should be possible for the implementation
to type the property with any supertype.
We implement the check this way.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
