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

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) */

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list