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

Sven Herzberg wrote:
> Hi Alessandro,
>
> Am Dienstag, den 15.07.2008, 17:04 +0200 schrieb Alessandro Vesely:
>> What would you say about that
>
> It's pretty nice, I only have two comments:
>
>  * you change "only for debugging" to "always for debugging", maybe you
>    should simply use "iff" (or the expanded version "if and only if")

Ehm... well, actually I hope some native English speaker may retouch
it before it is possibly committed. :-)

>  * you drop the section about downsides of the advanced debugging,
>    please keep them in there

I hadn't dropped it. I just reworded it, keeping mentions to added
memory stuff and mutex-acquired global vision.

This discussion reminds me that smc_notify_tree() does not actually
check which thread does a chunk belong to. Could that result in
misbehavior? For example, it looks perfectly legal for a producer
consumer pair of threads to carefully smuggle thread-categorized
chunks of memory from the former to the latter thread; or should that
deserve an optimization warning?

Maybe the doc should be more precise. I attach a second attempt.

Index: running.sgml
===================================================================
--- running.sgml (revision 7183)
+++ running.sgml (working copy)
@@ -149,14 +149,17 @@
   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 is for 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 storing size and address information
+  for each allocated chunk, and maintaining a global hash table of that data.
+  That way, multi-thread scalability is given up, and memory consumption is
+  increased. However, the resulting code usually performs acceptably well,
+  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>
     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