Commit Graph

8 Commits

Author SHA1 Message Date
Michael Catanzaro
a412ffe4d3 gatomicarray: suppress valgrind memory leak warnings
The problem occurs because we keep a pointer inside the allocated block,
instead of a pointer to the start of the block:

```
==180238== 16 bytes in 1 blocks are possibly lost in loss record 3,086 of 16,075
==180238==    at 0x483980B: malloc (vg_replace_malloc.c:309)
==180238==    by 0x548942C: g_malloc (gmem.c:102)
==180238==    by 0x54A4748: g_slice_alloc (gslice.c:1025)
==180238==    by 0x53D0AAF: freelist_alloc (gatomicarray.c:77)
==180238==    by 0x53D0B85: _g_atomic_array_copy (gatomicarray.c:133)
==180238==    by 0x53F8E6D: iface_node_set_offset_L (gtype.c:1347)
==180238==    by 0x53F91F1: type_node_add_iface_entry_W (gtype.c:1444)
==180238==    by 0x53F93DF: type_add_interface_Wm (gtype.c:1477)
==180238==    by 0x53FC946: g_type_add_interface_static (gtype.c:2852)
==180238==    by 0x4A3D53A: gtk_menu_shell_accessible_get_type_once (gtkmenushellaccessible.c:26)
==180238==    by 0x4A3D495: gtk_menu_shell_accessible_get_type (gtkmenushellaccessible.c:26)
==180238==    by 0x4C8AC44: gtk_menu_shell_class_init (gtkmenushell.c:424)
```

Note we cannot use VALGRIND_FREELIKE_BLOCK() in freelist_free() because we
have not actually freed the FreeListNode and need to dereference it in
freelist_alloc() to decide whether to reuse the block. That would result
in a use-after-free warning before we would get a chance to call
VALGRIND_MALLOCLIKE_BLOCK() in the reuse path.

Also note that this free list only ever grows: it never shrinks for the
lifetime of the application, so nothing here will ever be truely freed,
although unused elements are eligible for reuse.

Fix suggested by Philip Withnall

Related: #2076
2020-11-24 08:10:58 -06:00
Дилян Палаузов
512655aa12 minor typos in the documentation (a/an) 2019-08-24 19:14:05 +00:00
Sébastien Wilmet
6b948d9613 gobject/: LGPLv2+ -> LGPLv2.1+
All gobject/*.{c,h} files have been processed.

gmarshal.c and gmarshal.h don't have a license header.

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-24 11:58:19 +02:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Matthias Clasen
f2e00a07f4 Improvde #include order consistency
This was mostly fixed already, just re-fix a few details here.
https://bugzilla.gnome.org/show_bug.cgi?id=71704
2013-01-01 13:54:54 -05:00
Matthias Clasen
6e7a7052e0 Remove a redundant assertion
A gsize is never going below 0.
2011-06-14 18:51:57 -04:00
Haakon Sporsheim
4c55b45162 Don't do pointer arithmetics on void*
For instance MSVC doesn't like that.

Signed-off-by: Tor Lillqvist <tml@iki.fi>
2010-01-07 10:14:24 +02:00
Alexander Larsson
75ce4741f9 Add GAtomicArray for RCU-style lockless updates
This adds supports for a lock-less a non-shrinking growable array.
You can use it to do reads using no locks, as long as your read-code
can handle that during the read transaction the object can be modified
by another writer (but it will not change size or be freed), and you
can only trust the result once the transaction has finished successfully.

This doesn't free things like RCU normally does, instead it pushes the
memory on a free list that is reused for other atomic arrays.
2009-11-30 20:48:50 +01:00