Re: Astonishing allocation bug in glib-2.16.4 compiled with gcc 2.96

[Alessandro Vesely <vesely tana it>]

Sven Herzberg wrote:
> Am Dienstag, den 15.07.2008, 14:13 +0200 schrieb Alessandro Vesely:
> > I didn't mean glib's test suite. What I wanted to say is that any 
> > client program that has its own test suite should enable debug-blocks 
> > in it. The above page should explicitly encourage such practice, IMHO.
> > Overlapping variables not always result in program crashes, it can be 
> > worse.
>
> Feel free to provide a patch for the documentation. It's all in glib's
> subversion repository.

What would you say about that

Index: running.sgml
===================================================================
--- running.sgml	(revision 7183)
+++ running.sgml	(working copy)
@@ -149,14 +149,16 @@
 		  which performs sanity checks on the released memory slices.
 		  Invalid slice adresses or slice sizes will be reported and lead to
 		  a program halt.
-		  This option should only be used in debugging scenarios, because it
-		  significantly degrades GSlice performance. Extra per slice memory
-		  is requied to do the necessary bookeeping, and multi-thread scalability
-		  is given up to perform global slice validation.
-		  This option is mostly useful in scenarios where program crashes are encountered
-		  while GSlice is in use, but crashes cannot be reproduced with G_SLICE=always-malloc.
-		  A potential cause for such a situation that will be caught by G_SLICE=debug-blocks
-		  is e.g.:
+		  This option should always be used in debugging scenarios.
+		  In particular, client packages sporting their own test suite should
+		  <emphasis>always enable this option when running tests</emphasis>.
+		  Global slice validation is ensured by adding bookeeping information to each
+		  allocation and maintaining a global hash table of that data. Although
+		  multi-thread scalability is given up, the resulting code usually performs
+		  acceptably well, and better than 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>
 		    void *slist = g_slist_alloc(); /* void* gives up type-safety */
 		    g_list_free (slist);           /* corruption: sizeof (GSList) != sizeof (GList) */