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

[Alessandro Vesely <vesely tana it>]

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