! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
weird issue between awesome and xfpm systray
Status:
RESOLVED: FIXED
Product:
Xfce4-power-manager
Component:
General

Comments

Description Yves-Alexis Perez editbugs 2011-05-10 16:32:52 CEST
Hey,

I have a Debian user reporting a weird problem between xfpm and awesome systray. Basically, every time he suspends/resumes, the plugin takes twice the place in the systray.

As it doesn't happen with xfce4-panel, it seems related to awesome, but it's not sure what it's linked to. Upgrade logs shows that the user updated xcb-util packages around that time so it might be related but I'm out of ideas on how to debug this, so any help would be welcome.

Downstream bug is at http://bugs.debian.org/626224
Comment 1 Christophe 2011-09-22 14:36:28 CEST
This also happens with the fluxbox window manager.
Comment 2 Jan Jansky 2011-11-22 21:17:08 CET
I can confirm the bug is definitely _not_ only an issue with awesome.  I am using Openbox (3.5.0) with tint2 panel (0.11 svn) under an xfce4 session (4.8) on a Debian system.

When the xfpm icon is displayed in the panel, after resume from suspend/hibernation the xfpm "re-initializes" and creates a "new" icon in the panel leaving an unused blank space. As someone in the downstream Debian bugzilla stated, there is an observable second-or-two gap when, after resume from suspend, you can actually see as the "another" icon appears and leaves a blank space.

The blank icon space disappears either after killing and relaunching tint2 _or_ by calling "xfce4-power-manager --restart".  Both methods work.

The problem is obviously not awesome specific (the title of the bug report should be changed).

Best regards,
Jan Jansky

PS: there was other similar issue with gnome-power-manager and tint2 leaving a blank space in the panel (see here https://bbs.archlinux.org/viewtopic.php?id=104600)
Comment 3 Renato Botelho 2011-11-28 12:27:58 CET
I have this same problem on fedora 16, xfpm 1.0.10. When i run xfce4-power-manager --restart the "blank icons" disapear.
Comment 4 Martin Kourim 2011-12-18 12:21:57 CET
I've noticed the same problem also with trayer (and with awesome as well).

Restarting awesome or trayer doesn't help, xfce4-power-manager --restart helps.

This problem is now reported for awesome, tint2, fluxbox and trayer, so the title of the bug report should be changed.
Comment 5 ChriS 2011-12-18 12:36:18 CET
Suspend/resume is not needed to trigger the bug.  Simply (physically) removing and reinserting the battery produces the undesired behavior (one empty space for each action).
Comment 6 Henry Gebhardt 2012-02-29 14:31:41 CET
Created attachment 4243 
Fix empty systray icon in some panels on battery removal and addition

1.) Please test this patch.

2.) Is it the correct fix? It appears destroying a GtkStatusIcon should be enough to remove it from the tray. Yet that is not the case with the trays mentioned in this bug (add lxpanel to the list). So, should the trays be doing something different, or is this patch correct?
Comment 7 Renato Botelho 2012-02-29 14:44:56 CET
(In reply to comment #6)
> Created attachment 4243 
> Fix empty systray icon in some panels on battery removal and addition
> 
> 1.) Please test this patch.
> 
> 2.) Is it the correct fix? It appears destroying a GtkStatusIcon should be
> enough to remove it from the tray. Yet that is not the case with the trays
> mentioned in this bug (add lxpanel to the list). So, should the trays be doing
> something different, or is this patch correct?

Worked as expected for me on fedora 16 x86_64. Thanks!
Comment 8 Bruno Azzinnari 2012-03-01 14:49:44 CET
Hey!

I've been chasing this bug over the last week, and just today started looking for a way to submit the fix. Sadly, it seems I'm late for just one day ^^' But I guess it's cool that it is fixed anyway (my fix was the same, setting the icon visibility to FALSE before destroying the struct).

For next time, what's the common "protocol" to submit a patch? Just by attaching it here, it will be taken into account? I'm just starting "collaborating" in this way, so any insight will be appreciated.

Thanks!
Comment 9 Henry Gebhardt 2012-03-02 00:26:04 CET
(In reply to comment #8)
> Hey!
> 
> I've been chasing this bug over the last week, and just today started looking
> for a way to submit the fix. Sadly, it seems I'm late for just one day ^^' But
> I guess it's cool that it is fixed anyway (my fix was the same, setting the
> icon visibility to FALSE before destroying the struct).

Hehehe... :-) Maybe you can add a Signed-off-by line like they do with the kernel?

Good to know somebody else arrived at the same fix independently. Do you know why destroying a GtkStatusIcon is not enough to make it disappear entirely?

I am thinking there may be a memory leak here. To test this I modified the GtkStatusIcon tutorial from the gnome site to add and remove a status icon 5 times a second. The rss and vsz memory sizes increase in steps, on average linearly with time. You can get it here:
http://astro.uni-tuebingen.de/~gebhardt/gtk-status-icon-test.c
and a script to measure the vsz memory usage:
http://astro.uni-tuebingen.de/~gebhardt/mem_plot.sh

This also happens using xfce4-panel.

I don't know what to make of this. Is this a GTK+-2 bug? Should I file it elsewhere?

> 
> For next time, what's the common "protocol" to submit a patch? Just by
> attaching it here, it will be taken into account? I'm just starting
> "collaborating" in this way, so any insight will be appreciated.

This is also my first time contributing to xfce. Is there any other place the patch should be advertized?
Comment 10 Bruno Azzinnari 2012-03-05 00:56:07 CET
Nope, I don't have any idea as of why it would not be enough, but I noticed it was done for the adaptor icon so I figured I would just try with this one too.

Just for curiosity I tried your test and reproduced the problem, memory usage gets higher and higher as long as the calls are made. The weird thing is that it increases only every some seconds, and not immediately after each call... maybe is just a delay on the process monitoring mechanism?

Anyway, do you know where does your patch go now that you posted it here? I have already temporarily fixed it on my system, but it would be nice to see it included soon in one of the next Arch package updates I run.
Comment 11 Bruno Azzinnari 2012-03-05 01:22:41 CET
Created attachment 4248 
Patch to avoid warnings when calling xfpm_battery_notify_idle with an invalid data pointer

If two battery added/removed notifications happen very fast, the xfpm_battery_notify_idle callback set up to run with the recently added battery object as a parameter may be run after the new battery has already been destroyed.

One possible fix is this one: to check for a valid object before invoking the xfpm_battery_notify. The other one would be unregistering the callback, be it that it was already called and unregistered, or still hasn't.
Comment 12 Bruno Azzinnari 2012-03-05 01:28:00 CET
Sorry for the noise, I'm just just understanding how bugzilla works ^^' The bug my previous patch fixes is not directly related to this one, but I run into it by debugging the one this report refers, maybe there's no need to open another ticket and can be applied as well.

And my memory failed in my previous comment Henry, the adaptor icon wasn't being set to visible-FALSE either, as I realized from taking another look at your patch.
Comment 13 Yves-Alexis Perez editbugs 2013-03-26 21:57:20 CET
*** Bug 8424 has been marked as a duplicate of this bug. ***
Comment 14 Yves-Alexis Perez editbugs 2013-03-26 22:12:55 CET
It seems that the patch attached to the Debian bug at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=156;filename=09_fix-insert-battery.patch;att=1;bug=626224 fixes the issue for at least some people. I never was able to reproduce it so I can't confirm it works but at least it doesn't break.
Comment 15 Henry Gebhardt 2013-03-27 04:26:42 CET
(In reply to comment #14)
> It seems that the patch attached to the Debian bug at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=156;filename=09_fix-insert-
> battery.patch;att=1;bug=626224 fixes the issue for at least some people.

That is good news! It is the same patch as the one attached to this bug.
Comment 16 Yves-Alexis Perez editbugs 2013-07-25 07:40:55 CEST
Nick, seems that you commited a patch to xfpm, can you take a look at this one and commit it? Thanks!
Comment 17 Simon Steinbeiss editbugs 2014-05-29 12:12:20 CEST
As the trayicon has been replaced by a panel-plugin in git master, this bug no longer applies.

Bug #7603

Reported by:
Yves-Alexis Perez
Reported on: 2011-05-10
Last modified on: 2014-05-29
Duplicates (1):
  • 8424 xfce4-power-manager applet is generating spaces in lxpanel when changing power-mode (e.g. ac adapter off)

People

Assignee:
Ali Abdallah
CC List:
11 users

Version

Version:
1.0.10

Attachments

Additional information