Help!

gnome-panel sometimes freezes during aptitude upgrade

  
  
Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> GTK-GNOME RSS
Next:  RFC: New cycle of changes to brasero  
Author Message
Michel Dänzer
External


Since: May 14, 2006
Posts: 397
PostPosted: Tue Jun 12, 2007 3:50 pm    Post subject: gnome-panel sometimes freezes during aptitude upgrade
Archived from groups: linux>debian>maint>gtk>gnome (more info?)
Sometimes when I upgrade my system with aptitude, the panel freezes;
systray icons and some applets (I presume those running in a separate
process) keep working, but the foot menu doesn't, my auto-hidden top
panel doesn't unhide, adding or removing systray icons doesn't change
the panel size, etc.

I just attached gdb to the panel while it was in this state and got the
backtrace below. It looks like there's a deadlock because a signal is
received while in malloc, and the signal handler ends up calling free.

Any ideas where the signal and/or its handler are coming from, or
generally how to find out more when it happens again?


#0 0x0f0aa8e8 in __lll_lock_wait () from /lib/libc.so.6
#1 0x0f03ae34 in free () from /lib/libc.so.6
#2 0x0f1adc14 in _XReadPad () from /usr/lib/libX11.so.6
#3 0x0f1adf10 in _XReply () from /usr/lib/libX11.so.6
#4 0x0f19f44c in XSync () from /usr/lib/libX11.so.6
#5 0x0f7f8000 in IA__gdk_flush ()
at /tmp/buildd/gtk+2.0-2.10.12/gdk/x11/gdkevents-x11.c:2499
#6 0x0ff678a8 in gnome_gtk_module_info_get () from /usr/lib/libgnomeui-2.so.0
#7 <signal handler called>
#8 0x0f03b4c0 in _int_malloc () from /lib/libc.so.6
#9 0x0f03dad4 in malloc () from /lib/libc.so.6
#10 0x0ee7fdd4 in xmlParseVersionNum () from /usr/lib/libxml2.so.2
#11 0x0ee84b1c in xmlParseVersionInfo () from /usr/lib/libxml2.so.2
#12 0x0ee84c60 in xmlParseXMLDecl () from /usr/lib/libxml2.so.2
#13 0x0ee947c8 in xmlParseChunk () from /usr/lib/libxml2.so.2
#14 0x0e1840f4 in rsvg_error_quark () from /usr/lib/librsvg-2.so.2
#15 0x0e1b1f48 in fill_info ()
from /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so
#16 0x0f7371c0 in gdk_pixbuf_loader_write ()
from /usr/lib/libgdk_pixbuf-2.0.so.0
#17 0x0f9be480 in icon_info_ensure_scale_and_pixbuf (icon_info=0x1093ecf0,
scale_only=<value optimized out>)
at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkicontheme.c:2589
#18 0x0f9be974 in IA__gtk_icon_info_load_icon (icon_info=0x103b8700, error=0x0)
at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkicontheme.c:2756
#19 0x0f9c0a6c in IA__gtk_icon_theme_load_icon (
icon_theme=<value optimized out>, icon_name=0x10194448 "gnome-mime-text",
size=16, flags=0, error=0x0)
at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkicontheme.c:1414
#20 0x0fa66ccc in get_cached_icon (name=0x10194448 "gnome-mime-text",
pixel_size=16) at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkrecentmanager.c:1978
#21 0x0fa697b8 in IA__gtk_recent_info_get_icon (info=<value optimized out>,
size=16) at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkrecentmanager.c:2009
#22 0x0fa604d4 in idle_populate_func (data=0x10b3c500)
at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkrecentchoosermenu.c:802
#23 0x0f2c8e78 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0



--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Back to top
Michel Dänzer
External


Since: May 14, 2006
Posts: 397
PostPosted: Wed Jun 13, 2007 11:20 am    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
On Tue, 2007-06-12 at 20:00 +0200, Josselin Mouette wrote:
> Le mardi 12 juin 2007 à 15:45 +0200, Michel Dänzer a écrit :
> > #19 0x0f9c0a6c in IA__gtk_icon_theme_load_icon (
> > icon_theme=<value optimized out>, icon_name=0x10194448 "gnome-mime-text",
> > size=16, flags=0, error=0x0)
> > at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkicontheme.c:1414
> > #20 0x0fa66ccc in get_cached_icon (name=0x10194448 "gnome-mime-text",
> > pixel_size=16) at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkrecentmanager.c:1978
>
> Looks like a problem when rendering this icon.

So you think it crashed instead of getting an external signal? Why would
it crash inside malloc?

> Which icon theme are you using?

Gorilla. Would you like me to try another one to see if it happens as
well?


--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Back to top
Michel Dänzer
External


Since: May 14, 2006
Posts: 397
PostPosted: Wed Jun 13, 2007 12:10 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
On Wed, 2007-06-13 at 11:15 +0200, Michel Dänzer wrote:
> On Tue, 2007-06-12 at 20:00 +0200, Josselin Mouette wrote:
> > Le mardi 12 juin 2007 à 15:45 +0200, Michel Dänzer a écrit :
> > > #19 0x0f9c0a6c in IA__gtk_icon_theme_load_icon (
> > > icon_theme=<value optimized out>, icon_name=0x10194448 "gnome-mime-text",
> > > size=16, flags=0, error=0x0)
> > > at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkicontheme.c:1414
> > > #20 0x0fa66ccc in get_cached_icon (name=0x10194448 "gnome-mime-text",
> > > pixel_size=16) at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkrecentmanager.c:1978
> >
> > Looks like a problem when rendering this icon.
>
> So you think it crashed instead of getting an external signal? Why would
> it crash inside malloc?

BTW, I still have gdb attached to this instance, so let me know if
there's anything that could provide you.


--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Back to top
Gabor Gombas
External


Since: Mar 22, 2005
Posts: 154
PostPosted: Wed Jun 13, 2007 1:50 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
On Wed, Jun 13, 2007 at 11:15:33AM +0200, Michel Dänzer wrote:

> Gorilla. Would you like me to try another one to see if it happens as
> well?

I experienced this problem both on i386 and amd64 but I did not have
time so far to analyze the reasons. I _think_ I was using either the
SphereCrystal or the default theme (I don't have access to those
machines now), but definitely not Gorilla.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org
Back to top
Gabor Gombas
External


Since: Mar 22, 2005
Posts: 154
PostPosted: Wed Jun 13, 2007 2:10 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
On Wed, Jun 13, 2007 at 11:15:33AM +0200, Michel Dänzer wrote:

> So you think it crashed instead of getting an external signal? Why would
> it crash inside malloc?

Just guessing, but the backtrace looks like gnome-panel gets a SIGSEGV
due to previous heap corruption, and libgnomeui_segv_handle() calls
functions (in this case free()) that are not safe to be called from
signal context.

If you can reproduce the problem, you could try to launch gnome-panel
with --disable-crash-dialog and see what happens. If my guessing is
right it should die instead of freezing.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
Back to top
Michel Dänzer
External


Since: May 14, 2006
Posts: 397
PostPosted: Wed Jun 20, 2007 3:10 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
On Tue, 2007-06-12 at 20:00 +0200, Josselin Mouette wrote:
> Le mardi 12 juin 2007 à 15:45 +0200, Michel Dänzer a écrit :
> > #19 0x0f9c0a6c in IA__gtk_icon_theme_load_icon (
> > icon_theme=<value optimized out>, icon_name=0x10194448 "gnome-mime-text",
> > size=16, flags=0, error=0x0)
> > at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkicontheme.c:1414
> > #20 0x0fa66ccc in get_cached_icon (name=0x10194448 "gnome-mime-text",
> > pixel_size=16) at /tmp/buildd/gtk+2.0-2.10.12/gtk/gtkrecentmanager.c:1978
>
> Looks like a problem when rendering this icon. Which icon theme are you
> using?

It didn't happen for a while after changing icon theme, so I thought it
was indeed related to that, but it just happened again with a different
backtrace:

[...]
#6 0x0ff678a8 in gnome_gtk_module_info_get () from /usr/lib/libgnomeui-2.so.0
#7 <signal handler called>
#8 0x0efba4c0 in _int_malloc () from /lib/libc.so.6
#9 0x0efbcad4 in malloc () from /lib/libc.so.6
#10 0x0f5e1bf8 in cairo_font_options_create () from /usr/lib/libcairo.so.2
[...]

So maybe this is even a libc6 issue... I'll try to attach gdb to the
panel during upgrades from now on and see if I can find out anything
more then.


Thanks for the input so far,


--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Back to top
Sebastien Bacher
External


Since: Nov 08, 2004
Posts: 580
PostPosted: Wed Jun 20, 2007 4:00 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
Le mercredi 20 juin 2007 à 15:06 +0200, Michel Dänzer a écrit :

> So maybe this is even a libc6 issue... I'll try to attach gdb to the
> panel during upgrades from now on and see if I can find out anything
> more then.

That rather look like a corruption than something due to libc6, could
you try to get a valgrind log?


Sebastien Bacher



--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org
Back to top
Michel Dänzer
External


Since: May 14, 2006
Posts: 397
PostPosted: Thu Jun 21, 2007 10:40 am    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
On Wed, 2007-06-20 at 15:29 +0200, Sebastien Bacher wrote:
> Le mercredi 20 juin 2007 à 15:06 +0200, Michel Dänzer a écrit :
>
> > So maybe this is even a libc6 issue... I'll try to attach gdb to the
> > panel during upgrades from now on and see if I can find out anything
> > more then.
>
> That rather look like a corruption than something due to libc6, could
> you try to get a valgrind log?

The panel is quite sluggish running in valgrind, so I tried running it
with MALLOC_CHECK_=3 first. Didn't pick up anything, though this time I
attached gdb during the upgrade, and it's indeed a segfault in
_int_malloc, with yet another different backtrace. I'll restart the
panel in valgrind for the next upgrade.


--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Back to top
Michel Dänzer
External


Since: May 14, 2006
Posts: 397
PostPosted: Tue Jun 26, 2007 5:30 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
On Wed, 2007-06-20 at 15:29 +0200, Sebastien Bacher wrote:
> Le mercredi 20 juin 2007 à 15:06 +0200, Michel Dänzer a écrit :
>
> > So maybe this is even a libc6 issue... I'll try to attach gdb to the
> > panel during upgrades from now on and see if I can find out anything
> > more then.
>
> That rather look like a corruption than something due to libc6, could
> you try to get a valgrind log?

valgrind -v reported the following during an upgrade:

==14840== Conditional jump or move depends on uninitialised value(s)
==14840== at 0x100252A0: (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)
==14840==
==14840== Conditional jump or move depends on uninitialised value(s)
==14840== at 0x100252B4: (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)
==14840==
==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?


--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Back to top
Gabor Gombas
External


Since: Mar 22, 2005
Posts: 154
PostPosted: Wed Jun 27, 2007 11:50 am    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
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. Btw. did you
use "--partial-loads-ok=yes"? That can avoid some of the false positives
(and in some rare cases can miss valid errors, but I doubt that would be
the case with gnome-panel).

If there were no messages relating to SIGSEGV or invalid read/write,
then I think you did not manage to trigger the bug this time.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org
Back to top
Michel Dänzer
External


Since: May 14, 2006
Posts: 397
PostPosted: Wed Jun 27, 2007 12:10 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
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?

> Btw. did you use "--partial-loads-ok=yes"? That can avoid some of the false positives
> (and in some rare cases can miss valid errors, but I doubt that would be
> the case with gnome-panel).

I don't think I need it until there's too many of the above cluttering
up the output, but I'll keep it in mind, thanks.

> If there were no messages relating to SIGSEGV or invalid read/write,
> then I think you did not manage to trigger the bug this time.

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.


--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Back to top
Gabor Gombas
External


Since: Mar 22, 2005
Posts: 154
PostPosted: Wed Jun 27, 2007 1:10 pm    Post subject: Re: gnome-panel sometimes freezes during aptitude upgrade [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
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 Smile

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
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org
Back to top
Display posts from previous:   
Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> GTK-GNOME All times are: Eastern Time (US & Canada) (change)
Page 1 of 1

 
 You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum