Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

reload_config causes systray (GDK) windows to die #4897

Open
2 tasks done
ervinpopescu opened this issue Jun 23, 2024 · 14 comments
Open
2 tasks done

reload_config causes systray (GDK) windows to die #4897

ervinpopescu opened this issue Jun 23, 2024 · 14 comments
Labels
status: unconfirmed

Comments

@ervinpopescu
Copy link
Contributor

ervinpopescu commented Jun 23, 2024 •
edited
Loading

Issue description

Example of blueman-tray output:

$ blueman-tray

(blueman-tray:58207): Gdk-WARNING **: 15:02:59.366: GdkWindow 0x2a00003 unexpectedly destroyed

(blueman-tray:58207): Gdk-WARNING **: 15:02:59.366: The program 'blueman-tray' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 281 error_code 3 request_code 18 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Similar behavior with:

mictray
nm-applet
blueman-applet
systray_profile.py (custom GDK app)
pa-applet

With the default config:

$ blueman-tray

(blueman-tray:73413): Gdk-WARNING **: 15:13:19.501: GdkWindow 0x2a00002 unexpectedly destroyed

(blueman-tray:73413): Gdk-WARNING **: 15:13:19.502: The program 'blueman-tray' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
  (Details: serial 281 error_code 143 request_code 139 (RENDER) minor_code 7)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Not sure why the difference in errors. RenderBadPicture (invalid Picture parameter) vs BadWindow (invalid Window parameter)

flameshot (qt) is fine, so this is why I ruled out qt.

I would like some pointers for further debugging in addition to the current info returned by the error, if that's possible. Thanks in advance!

Version

0.26.1.dev30 ge2158512

Backend

X11 (default)

Config

No response

Logs

No response

Required

  • I have searched past issues to see if this bug has already been reported, and it hasn't been.
  • I understand that people give their precious time for free, and thus I've done my very best to make this problem as easy as possible to investigate.
@ervinpopescu
Copy link
Contributor Author

Update: I bisected this to 7c3fbef. @tych0 any idea why this happened and how we can fix it?

@ervinpopescu
Copy link
Contributor Author

ervinpopescu commented Jun 23, 2024 •
edited
Loading

Is it just that Systray kills the window when Systray.finalize is called in Bar.finalize?

@tych0
Copy link
Member

tych0 commented Jun 23, 2024

Yeah, I think you're exactly right. So we need to do some magic there when we're reloading to propagate the window(s) in the systray across, but delete the drawers (or maybe propagate all of those too?). Oof :(

@ervinpopescu
Copy link
Contributor Author

Oof :(

:)

Why does flameshot (i.e. qt) not get killed?

@tych0
Copy link
Member

tych0 commented Jun 23, 2024

Maybe it does, but it's smart enough to re-register? Not sure.

@tych0
Copy link
Member

tych0 commented Jun 23, 2024

Hmm, this is weird. I wouldn't have expected a behavior change for non-WidgetBox using bars based on that patch. So clearly I don't understand something about how this is supposed to work :)

@ervinpopescu
Copy link
Contributor Author

QQ: Have you managed to reproduce this?

@tych0
Copy link
Member

tych0 commented Jul 2, 2024

I haven't had time to try yet, but I can definitely believe it's an issue. We should revert if it's an issue and we want to release, otherwise i'll try to track it down asap, probably next week.

@elParaguayo
Copy link
Member

I don't think we need a new release yet so let's fix this if we can.

@ervinpopescu
Copy link
Contributor Author

I'm fine with just running v0.26.0 and I don't see other people complaining, so I would say that a revert is not necessary as well.

Thanks for looking into it @tych0!

tych0 added a commit to tych0/qtile that referenced this issue Jul 11, 2024
@tych0
Revert "remember to finalize widgets"
cd93fb0 
This reverts commit 7c3fbef.

We have a more serious bug (systray windows dying) reported with this
commit than the simple memory leak it fixes. We want to do a release to
capture other fixes, so let's revert this for now.

See qtile#4897
@tych0 tych0 mentioned this issue Jul 11, 2024
Merged
jwijenbergh pushed a commit that referenced this issue Jul 11, 2024
@tych0 @jwijenbergh
Revert "remember to finalize widgets"
2be6b7e 
This reverts commit 7c3fbef.

We have a more serious bug (systray windows dying) reported with this
commit than the simple memory leak it fixes. We want to do a release to
capture other fixes, so let's revert this for now.

See #4897
@jwijenbergh
Copy link
Contributor

Fixed in git

@tych0
Copy link
Member

tych0 commented Jul 12, 2024

Can we leave this one open? Ultimately we want to keep something like the patch so we don't leak widgets, but we need to find some way to persist them when we are restarting. I don't think it should be too hard to do, but I would like to have a reminder here :)

@tych0 tych0 reopened this Jul 12, 2024
@jwijenbergh
Copy link
Contributor

Ok no worries, sorry for closing!

@tych0
Copy link
Member

tych0 commented Jul 12, 2024

All good, you are right that it is fixed right now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: unconfirmed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tych0 @elParaguayo @jwijenbergh @ervinpopescu