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
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.
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
g_queue_free_full(), to free a Queue including its dynamically-allocated elements.
On similar lines to List and Slist.
void g_queue_free_full (GQueue *queue, GDestroyNotify free_func);
Test case covering g_queue_free_full() is added.
Added export symbol to glib.symbols.
Closes Bug: https://bugzilla.gnome.org/show_bug.cgi?id=657433
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
foo_free is conceptually "worth" one unref; not decrementing the
refcount here means the GArray or GPtrArray wrapper (but not its
contents) would leak in the following call sequence:
p = g_ptr_array_new ();
g_ptr_array_ref (p);
g_ptr_array_free (p, TRUE);
g_ptr_array_unref (p);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Depending how the array is freed, we may want to free the underlying
array (the "segment"), the struct wrapper or both.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
First, some ARM systems are not fast enough to meet the 30 second
deadline in gwakeuptest.c, so increase that to 60.
Second, we have some signed/unsigned woes in the gparam transform tests.
On success, g_option_context_parse alters argv by removing options that
it understood, so g_strfreev is insufficient. Instead, take a shallow
copy and free all of the arguments in that, then free the array argv
but not its contents.
Also, improve the checks in error cases, by checking that argv has
not been altered in this way.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
These don't really matter, since it's test code, but they do obscure
real leaks in the library.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
Removing the last thing in a dataset frees the dataset, and if the
datalist was in a dataset, we can't safely unlock it after the dataset
has been freed. Unlock it sooner.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
Calling this function with a NULL argument is considered to be invalid,
but one of the regression tests does it anyway (to watch it crash), which
seems a good indication that it's expected to be somewhat common.
Let's check it rather than segfaulting.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
These were leaked. Valgrind was sad.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Also document why we're not actually using the buffer for anything.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
In practice, the uninitialized refcount will typically mean that the copy is
never freed, and leaks.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Raised by Matthias in bgo#665685 but which I didn't spot until after pushing
commit 3ac7c35656649b1d1fcf2ccaa670b854809d4cd8.
Renames G_UNICHAR_MAX_DECOMPOSITION_LEN to G_UNICHAR_MAX_DECOMPOSITION_LENGTH
and fixes a few documentation issues.
See: bgo#665685
These prevent GVariants from accidentally being brought back to life after
being freed, and should make it easier to track down ref. counting issues.
Closes: bgo#665184
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
