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
