luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-02-12 13:49:22 +01:00
Code Issues Packages Projects Releases Wiki Activity

Improve docs

Browse Source 
svn path=/trunk/; revision=7188
This commit is contained in:
Matthias Clasen 2008-07-16 04:24:56 +00:00
parent 9f3f5f0905
commit 652e750737
2 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/reference/ChangeLog
View File

@ -1,3 +1,10 @@
2008-07-16 Matthias Clasen <mclasen@redhat.com>
Bug 543168 – Description of G_SLICE=debug-blocks discourages its use
* glib/running.sgml: Improve docs of G_SLICE=debug-blocks.
Patch by Alessandro Vesely.
2008-07-08 Matthias Clasen <mclasen@redhat.com> 2008-07-08 Matthias Clasen <mclasen@redhat.com>
* gio/gio-sections.txt: Add new GMount functions * gio/gio-sections.txt: Add new GMount functions

19
docs/reference/glib/running.sgml
View File

@ -149,14 +149,17 @@ variables like <envar>LANG</envar>, <envar>PATH</envar> or <envar>HOME</envar>.
which performs sanity checks on the released memory slices. which performs sanity checks on the released memory slices.
Invalid slice adresses or slice sizes will be reported and lead to Invalid slice adresses or slice sizes will be reported and lead to
a program halt. a program halt.
This option should only be used in debugging scenarios, because it This option is for debugging scenarios.
significantly degrades GSlice performance. Extra per slice memory In particular, client packages sporting their own test suite should
is requied to do the necessary bookeeping, and multi-thread scalability <emphasis>always enable this option when running tests</emphasis>.
is given up to perform global slice validation. Global slice validation is ensured by storing size and address information
This option is mostly useful in scenarios where program crashes are encountered for each allocated chunk, and maintaining a global hash table of that data.
while GSlice is in use, but crashes cannot be reproduced with G_SLICE=always-malloc. That way, multi-thread scalability is given up, and memory consumption is
A potential cause for such a situation that will be caught by G_SLICE=debug-blocks increased. However, the resulting code usually performs acceptably well,
is e.g.: possibly better than with comparable memory checking carried out using
external tools. An example of a memory corruption scenario that cannot be
reproduced with <literal>G_SLICE=always-malloc</literal>, but will be caught
by <literal>G_SLICE=debug-blocks</literal> is as follows:
<programlisting> <programlisting>
void *slist = g_slist_alloc(); /* void* gives up type-safety */ void *slist = g_slist_alloc(); /* void* gives up type-safety */
g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */ g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */