-
-
Notifications
You must be signed in to change notification settings - Fork 589
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.
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
Reloading picom crashes #381
Comments
It only crashes if I have both |
|
|
That's the stack trace for the signal SIGUSR1 you sent, not for the segmentation fault. You need to continue. Also it appears your picom is not built with debug symbols, or is stripped (nix does that). |
Oohps, sorry. Not very familiar with debugging. 🙂 Here's a new try:
|
I tried again with
|
Seems to be a bit random what the backtrace is exactly. |
in both cases these stack traces are not related to the picom. the first one ends in similar stack traces: #205 (solved with a system update), #265 (unsolved) |
@jluttine Does |
@yshui Doesn't seem to have! I ran |
@jluttine I remember fixing a similar problem for the experimental backends. I will see what can be done. |
@jluttine I applied the same fix i used for the experimental backends. Can you git pull and try it? |
So we don't reuse the old, freed fbcfg across reset. Related: #381 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Because it needs to be cleared when we reset, so we don't use a freed fbconfig across reset. Related: #381 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
@jluttine should be fixed now. can you try again? |
@yshui Yes, now it works! Thanks a lot! 👍 So was the bug in the drivers (as the backtrace suggested?) and you just made somw workarounds on picom side, or was it a bug on picom side? Just curious to learn about debugging. |
@jluttine It was a picom bug. We kept some pointers to data freed during reset. |
Bisecting tells 754531e made switching workspace to one having a lot of windows really slow here (in fact there are only two windows drawn at all times and a lot of WM-drawn tab titles, but i don't know if picom understands that or if it doesn't like something else; top shows that picom consumes a lot of CPU; WM is xmonad): |
After further poking around it became clear that the aforementioned commit only removes the "caching" effect of picom: first time picom shows that workspace it is always slow. Bisecting this slowness found that 519bf85 is the first bad commit. |
519bf85 is probably all right, it just makes (And yeah, this is why I've stuck with compton 7.4, because I never got around to investigating/bisecting this. I honestly can't grasp how people can live with it. It's unbearably slow.) |
@l29ah Are you still experiencing this slowness? I tried a recent release of picom a couple weeks ago and it's still there, so I'm still stuck on 7.4, after all these years. Suppose we should open a new issue for this… :-) |
I didn't try the new release since my slowness-reverting patch won't apply to it. |
@liskin hey, can you open a new issue for the slowness you described? i missed it because this is a closed issue about picom crashes... |
@liskin btw the two commits you are pointing to have nothing to do with this. |
This should marginally speed up pixmap binding for the glx backend (we don't need FBConfigs for egl). Fix a long running complaint in #381 (unrelated issue, but there is complaint in there about glXChooseFBConfig being called whenever we bind a new pixmap). Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
also, try the egl backend. |
This should marginally speed up pixmap binding for the glx backend (we don't need FBConfigs for egl). Fix a long running complaint in #381 (unrelated issue, but there is complaint in there about glXChooseFBConfig being called whenever we bind a new pixmap). Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This should marginally speed up pixmap binding for the glx backend (we don't need FBConfigs for egl). Fix a long running complaint in #381 (unrelated issue, but there is complaint in there about glXChooseFBConfig being called whenever we bind a new pixmap). Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This should marginally speed up pixmap binding for the glx backend (we don't need FBConfigs for egl). Fix a long running complaint in #381 (unrelated issue, but there is complaint in there about glXChooseFBConfig being called whenever we bind a new pixmap). Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This should marginally speed up pixmap binding for the glx backend (we don't need FBConfigs for egl). Fix a long running complaint in #381 (unrelated issue, but there is complaint in there about glXChooseFBConfig being called whenever we bind a new pixmap). Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This should marginally speed up pixmap binding for the glx backend (we don't need FBConfigs for egl). Fix a long running complaint in #381 (unrelated issue, but there is complaint in there about glXChooseFBConfig being called whenever we bind a new pixmap). Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Apologies for being late to this. I confirm the referenced commit fixes this for me, and also that the issue isn't present with the egl backend. Thanks! |
Platform
NixOS (nixos-unstable).
GPU, drivers, and screen setup
Laptop, no external monitors, no graphics card (except what's inside Intel's own CPU or so).
Environment
Plain i3 with sddm as the display manager.
picom version
v7
I'm using the latest commit
17831a7be3ecf02b874738009fbb2e244de6bd67
.Configuration:
/path/to/picom.conf
:Steps of reproduction
picom --config=/path/to/picom.conf
.pkill -USR1 picom
Expected behavior
Picom should keep running normally and just reload the configuration.
Current Behavior
Picom crashes.
Stack trace
I couldn't find information on how to build with debug info. Can you point me to the source of that information? I couldn't find that info in the readme nor here: https://github.com/yshui/picom/wiki/Reporting-issues
Other details
The text was updated successfully, but these errors were encountered: