[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: The magazine_chain_pop_head() problem
From:       Bastien Nocera <hadess () hadess ! net>
Date:       2010-12-08 10:55:08
Message-ID: 1291805709.8919.19.camel () novo ! hadess ! net
[Download RAW message or body]

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


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

[prev in list] [next in list] [prev in thread] [next in thread]