Re: gnome-panel sometimes freezes during aptitude upgrade
On Wed, Jun 27, 2007 at 12:05:06PM +0200, Michel Dänzer wrote:
> On Wed, 2007-06-27 at 11:39 +0200, Gabor Gombas wrote:
> > On Tue, Jun 26, 2007 at 05:21:40PM +0200, Michel Dänzer wrote:
> >
> > > ==14840== Conditional jump or move depends on uninitialised value(s)
> > > ==14840== at 0x100252D0: (within /usr/bin/gnome-panel)
> > > ==14840== by 0xF333B18: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1200.12)
> > > ==14840== by 0xF322DC8: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.12)
> > > ==14840== by 0xF337370: (within /usr/lib/libgobject-2.0.so.0.1200.12)
> > > ==14840== by 0xF338678: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.12)
> > > ==14840== by 0xF338848: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1200.12)
> > > ==14840== by 0xF974258: ensure_valid_themes (gtkicontheme.c:1208)
> > > ==14840== by 0xF9743F0: _gtk_icon_theme_check_reload (gtkicontheme.c:3107)
> > > ==14840== by 0xFB1B1EC: gtk_window_client_event (gtkwindow.c:4872)
> > > ==14840== by 0xF9B81F0: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
> > > ==14840== by 0xF321008: (within /usr/lib/libgobject-2.0.so.0.1200.12)
> > > ==14840== by 0xF322DC8: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.12)
> > >
> > >
> > > Does that ring any bells, or (how) can I get more information out of
> > > valgrind?
> >
> > My feeling is that this is a false positive (which is very often the
> > case with "unitialized value" warnings from valgrind). If anything
> > inside the icon_theme structure at gtkicontheme.c:1208 would be really
> > uninitialized you'd get some kind of error much earlier.
>
> I'm a valgrind newbie, but doesn't the above indicate the problem is
> somewhere in /usr/bin/gnome-panel, not at gtkicontheme.c:1208?
The bug is definitely not at gtkicontheme.c:1208, but that is a very
simple call to g_signal_emit() with just one non-trivial data structure
referenced, namely the icon_theme variable. So this is a good starting
point. Now, icon_theme describes the icon theme that is currently used,
so if anything inside that data structure (including the whole object
tree its members point to) would be really uninitialized, you'd likely
get some error messages much earlier.
It is of course possible that during the signal delivery some callback
modified the data structure and introduced a pointer to some
uninitialized memory, but I think that is unlikely (I can be wrong of
course).
Why I think so? Two reasons: unitialized memory warnings are most of the
time false positives. Take an example:
int foo(int a)
{
int b;
if (a > 5)
b = 1;
b++;
if (a > 5)
return b;
return 0;
}
So b can be used uninitialized, but when it is, it's value won't affect
the program execution. While this seems silly, this kind of trick is
often used in OpenSSL for example, and I think it can also occur due to
optimizations when the compiler re-orders code. An other example is an
optimized strlen()-like function, which "knows" that when the string is
properly aligned, the memory can be loaded in large chunks without
risking a page fault past the end of the string. In this case valgrind
sees that the memory past the string was loaded into a register but it
does not know that those uninitialized bytes were never used.
The other reason why the valgrind errors you mentioned do not seem
critical is that the bug we want to catch is a crash. Uninitialized
accesses do not cause a crash. Of course if you _reference_ something
through an uninitialized pointer then you have a real problem, but then
valgrind will either log "Invalid read of size XXX"/"Invalid write of
size XXX" etc. errors or it will simply say that the program got a
SIGSEGV. So until you see something similar it does not worth spending
too much time tracking down messages about uninitialized memory access.
> Okay, I'll keep trying. Note that bug #430630 didn't crash when running
> in valgrind either, though it did flag the invalid memory access.
When valgrind (or more precisely the memcheck skin) finds heap
corruption it fixes that up and allows the application to run further,
as if nothing has happened. This way you can find multiple bugs with a
single valgrind run :-)
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
Laboratory of Parallel and Distributed Systems
Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary
Phone/Fax : +36 1 329-78-64 (secretary)
W3 : http://www.lpds.sztaki.hu
---------------------------------------------------------
Reply to: