Re: The magazine_chain_pop_head() problem

[Bastien Nocera <hadess hadess net>]

On Wed, 2010-12-08 at 11:35 +0100, Yann Droneaud wrote:
> Le mercredi 08 décembre 2010 à 09:58 +0000, Bastien Nocera a écrit :
> > On Wed, 2010-12-08 at 08:48 +0100, Yann Droneaud wrote:
> > > (I've already send this message, but it seems it was lost in moderation)
> > <snip>
> > > So I'm stuck.
> > > 
> > > If this bug could not be reproduced for debug, debug support should be added/enabled in the code
> > > to try to discover the culprit. Any ideas ? ;)
> > 
> > It's possible the slice allocator has bugs, but the more probable reason
> > for those crashes is memory corruption and double-frees in the affected
> > code. Each bug should be treated as separate ones until root-caused.
> > 
> 
> So, you think running programs with G_SLICE=always-malloc (under
> valgrind) will uncover the real bugs ?
> 
> Or will it hide them ?

It depends whether the bugs are in the slice allocator or the programs
themselves. As I'm pretty sure the problems are in the programs, it
wouldn't hide them.

> Enabling G_SLICE=always-malloc fully bypass the multi-threaded slice
> allocator code, so if the problem is lying on a corner case of the
> thread access, we're going to miss it.

Right, but you'd need to come up with more than circumspect evidence
that the bug lies in the slice allocator though.

> So I'm currently running my desktop with G_SLICE=debug-blocks, at least
> it could detect double free, but not memory overflow.

Cheers