==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
Simplify some of the logic in this function.
1) Simplify flag checks as per Colin's suggestions in
https://bugzilla.gnome.org/show_bug.cgi?id=605667
2) Don't repeatedly recheck if class_pspec is NULL.
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
GObject enforces the following restrictions on property overrides:
- must only add abilities: if the parent class supports
readability/writability then the subclass must also support them.
Subclasses are free to add readability/writability.
- must not add additional restrictions: if the parent class doesn't
have construct/construct-only restrictions then the subclass must
not add them. Subclasses are free to remove restrictions.
The problem with the previous implementation is that the check against
adding construct/construct-only restrictions was being done even if the
property was not previously writable. As an example:
"readable" and "writable only on construct"
was considered as being more restrictive than
"read only".
This patch tweaks the check to allow the addition of
construct/construct-only restrictions for properties that were
previously read-only and are now being made writable.
https://bugzilla.gnome.org/show_bug.cgi?id=666615
There are some races in the condition variable emulation code for
Windows XP with respect to timeouts while waiting.
First, in the event of a timeout, we never remove the waiter from the
condition variable. This can cause crashes later. That problem was
found by Rodrigo Rivas Costa.
Second, if the waiting thread times out and exits just as we were about
to call SetEvent() on its waiter event, we could end up trying to access
the waiter after it was closed/freed. We need to hold on to the lock a
little bit longer to ensure that that's not possible.
https://bugzilla.gnome.org/show_bug.cgi?id=666551
