Reloading picom crashes #381

jluttine · 2020-04-17T02:25:23Z

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

$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) (0x416)
    Version: 20.0.2
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.0.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 20.0.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.0.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Environment

Plain i3 with sddm as the display manager.

picom version

v7

I'm using the latest commit 17831a7be3ecf02b874738009fbb2e244de6bd67.

$ picom --diagnostics
**Version:** v7

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes* Config file used: None

### Drivers (inaccurate):

modesetting

Configuration:

/path/to/picom.conf:

shadow = true;
backend = "glx";

Steps of reproduction

In one terminal, run picom --config=/path/to/picom.conf.
In another terminal, run pkill -USR1 picom

Expected behavior

Picom should keep running normally and just reload the configuration.

Current Behavior

Picom crashes.

Segmentation fault (core dumped)

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:

jluttine · 2020-04-17T02:27:18Z

It only crashes if I have both shadow=true; and backend="glx";.

yshui · 2020-04-17T14:23:00Z

$ meson --buildtype=debug . build
$ ninja -C build

jluttine · 2020-04-17T16:12:39Z

$ gdb picom
GNU gdb (GDB) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from picom...
(No debugging symbols found in picom)
(gdb) start
Temporary breakpoint 1 at 0x40aaf0
Starting program: /nix/store/xlij3r6h89qhxmpm98lkbljmaa13ac8m-system-path/bin/picom
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libthread_db.so.1".

Temporary breakpoint 1, 0x000000000040aaf0 in main ()
(gdb) c
Continuing.
[New Thread 0x7fffe907f700 (LWP 24635)]
[New Thread 0x7fffe887e700 (LWP 24636)]
[New Thread 0x7fffe3fff700 (LWP 24637)]
[New Thread 0x7fffe37fe700 (LWP 24638)]

Thread 1 "picom" received signal SIGUSR1, User defined signal 1.
0x00007ffff79a2d6f in epoll_wait () from /nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libc.so.6
(gdb) bt
#0  0x00007ffff79a2d6f in epoll_wait () from /nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libc.so.6
#1  0x00007ffff7e81f5b in epoll_poll () from /nix/store/19iq0g2dskxkib31rba64w8iblxl185x-libev-4.33/lib/libev.so.4
#2  0x00007ffff7e84a5a in ev_run () from /nix/store/19iq0g2dskxkib31rba64w8iblxl185x-libev-4.33/lib/libev.so.4
#3  0x000000000040c269 in main ()

yshui · 2020-04-17T16:13:45Z

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

jluttine · 2020-04-18T06:36:50Z

Oohps, sorry. Not very familiar with debugging. 🙂 Here's a new try:

Reading symbols from picom...
(gdb) start
Temporary breakpoint 1 at 0x40aaf0: file ../src/picom.c, line 2331.
Starting program: /nix/store/yjpsd5yvsz83sdgcgh42f5l5m40yj170-picom-7.5/bin/picom --config /home/jluttine/.config/nide/picom.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libthread_db.so.1".

Temporary breakpoint 1, main (argc=3, argv=0x7fffffffd228) at ../src/picom.c:2331
2331    int main(int argc, char **argv) {
(gdb) c
Continuing.
[New Thread 0x7fffe907f700 (LWP 18777)]
[New Thread 0x7fffe887e700 (LWP 18778)]
[New Thread 0x7fffe3fff700 (LWP 18779)]
[New Thread 0x7fffe37fe700 (LWP 18780)]

Thread 1 "picom" received signal SIGUSR1, User defined signal 1.
0x00007ffff79a2d6f in epoll_wait () from /nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libc.so.6
(gdb) c
Continuing.
[Thread 0x7fffe37fe700 (LWP 18780) exited]
[Thread 0x7fffe3fff700 (LWP 18779) exited]
[Thread 0x7fffe887e700 (LWP 18778) exited]
[Thread 0x7fffe907f700 (LWP 18777) exited]
[New Thread 0x7fffe37fe700 (LWP 18791)]
[New Thread 0x7fffe3fff700 (LWP 18792)]
[New Thread 0x7fffe887e700 (LWP 18793)]
[New Thread 0x7fffe907f700 (LWP 18794)]

Thread 1 "picom" received signal SIGSEGV, Segmentation fault.
0x00007fffe958f13a in intelCreateBuffer () from /run/opengl-driver/lib/dri/i965_dri.so
(gdb) bt
#0  0x00007fffe958f13a in intelCreateBuffer () from /run/opengl-driver/lib/dri/i965_dri.so
#1  0x00007fffe95ffdd7 in driCreateNewDrawable () from /run/opengl-driver/lib/dri/i965_dri.so
#2  0x00007fffea33c348 in loader_dri3_drawable_init () from /run/opengl-driver/lib/libGLX_mesa.so.0
#3  0x00007fffea32fc4f in dri3_create_drawable () from /run/opengl-driver/lib/libGLX_mesa.so.0
#4  0x00007fffea31e376 in CreateDRIDrawable () from /run/opengl-driver/lib/libGLX_mesa.so.0
#5  0x00007fffea31e9c2 in CreateDrawable () from /run/opengl-driver/lib/libGLX_mesa.so.0
#6  0x00007ffff7838e81 in glXCreatePixmap () from /nix/store/xl3cr8kwlpi0j7il0zx4cb6sw05wx40g-libglvnd-1.2.0/lib/libGLX.so.0
#7  0x000000000042ae42 in glx_bind_pixmap (ps=ps@entry=0x81c970, pptex=pptex@entry=0x504920, pixmap=90178117, width=1956,
    width@entry=0, height=63, height@entry=0, repeat=repeat@entry=false, fbcfg=0x80d510) at ../src/opengl.c:538
#8  0x0000000000420037 in paint_bind_tex (force=false, visual=0, depth=32, repeat=false, hei=0, wid=0, ppaint=0x504918, ps=0x81c970)
    at ../src/render.c:94
#9  win_paint_shadow (reg_paint=0x7fffffffcd40, w=0x504740, ps=0x81c970) at ../src/render.c:608
#10 paint_all (ps=0x81c970, t=<optimized out>, ignore_damage=<optimized out>) at ../src/render.c:901
#11 0x000000000040fb15 in _draw_callback (loop=0x7ffff7e8d720 <default_loop_struct>, ps=0x81c970, revents=8192) at ../src/picom.c:1444
#12 0x000000000040fa8e in _draw_callback (loop=0x7ffff7e8d720 <default_loop_struct>, ps=0x81c970, revents=8192) at ../src/picom.c:1425
#13 0x0000000000410369 in draw_callback (loop=0x7ffff7e8d720 <default_loop_struct>, w=0x81ca30, revents=<optimized out>)
    at ../src/picom.c:1466
#14 0x00007ffff7e81613 in ev_invoke_pending () from /nix/store/19iq0g2dskxkib31rba64w8iblxl185x-libev-4.33/lib/libev.so.4
#15 0x00007ffff7e84f62 in ev_run () from /nix/store/19iq0g2dskxkib31rba64w8iblxl185x-libev-4.33/lib/libev.so.4
#16 0x000000000040c269 in session_run (ps=0x81c970) at ../src/picom.c:2325
#17 main (argc=3, argv=0x7fffffffd228) at ../src/picom.c:2426
(gdb) q
A debugging session is active.

        Inferior 1 [process 18773] will be killed.

Quit anyway? (y or n) y

jluttine · 2020-04-18T10:21:20Z

I tried again with debugoptimized build type and got a bit different backtrace (or maybe the backtrace is just a bit random anyway?):

Thread 1 "picom" received signal SIGUSR1, User defined signal 1.
0x00007ffff79a2d6f in epoll_wait () from /nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libc.so.6
(gdb) c
Continuing.
[Thread 0x7fffe3fff700 (LWP 7755) exited]
[Thread 0x7fffe37fe700 (LWP 7756) exited]
[Thread 0x7fffe887e700 (LWP 7754) exited]
[Thread 0x7fffe907f700 (LWP 7753) exited]
[New Thread 0x7fffe37fe700 (LWP 7770)]
[New Thread 0x7fffe3fff700 (LWP 7771)]
[New Thread 0x7fffe887e700 (LWP 7772)]
[New Thread 0x7fffe907f700 (LWP 7773)]

Thread 1 "picom" received signal SIGSEGV, Segmentation fault.
0x00007fffea31e359 in CreateDRIDrawable () from /run/opengl-driver/lib/libGLX_mesa.so.0
(gdb) bt
#0  0x00007fffea31e359 in CreateDRIDrawable () from /run/opengl-driver/lib/libGLX_mesa.so.0
#1  0x00007fffea31e9c2 in CreateDrawable () from /run/opengl-driver/lib/libGLX_mesa.so.0
#2  0x00007ffff7838e81 in glXCreatePixmap () from /nix/store/xl3cr8kwlpi0j7il0zx4cb6sw05wx40g-libglvnd-1.2.0/lib/libGLX.so.0
#3  0x000000000042ae42 in glx_bind_pixmap (ps=ps@entry=0x7ebcf0, pptex=pptex@entry=0x5039f0, pixmap=90178120, width=1956,
    width@entry=0, height=63, height@entry=0, repeat=repeat@entry=false, fbcfg=0x7f9750) at ../src/opengl.c:538
#4  0x0000000000420037 in paint_bind_tex (force=false, visual=0, depth=32, repeat=false, hei=0, wid=0, ppaint=0x5039e8, ps=0x7ebcf0)
    at ../src/render.c:94
#5  win_paint_shadow (reg_paint=0x7fffffffcd40, w=0x503810, ps=0x7ebcf0) at ../src/render.c:608
#6  paint_all (ps=0x7ebcf0, t=<optimized out>, ignore_damage=<optimized out>) at ../src/render.c:901
#7  0x000000000040fb15 in _draw_callback (loop=0x7ffff7e8d720 <default_loop_struct>, ps=0x7ebcf0, revents=8192) at ../src/picom.c:1444
#8  0x000000000040fa8e in _draw_callback (loop=0x7ffff7e8d720 <default_loop_struct>, ps=0x7ebcf0, revents=8192) at ../src/picom.c:1425
#9  0x0000000000410369 in draw_callback (loop=0x7ffff7e8d720 <default_loop_struct>, w=0x7ebdb0, revents=<optimized out>)
    at ../src/picom.c:1466
#10 0x00007ffff7e81613 in ev_invoke_pending () from /nix/store/19iq0g2dskxkib31rba64w8iblxl185x-libev-4.33/lib/libev.so.4
#11 0x00007ffff7e84f62 in ev_run () from /nix/store/19iq0g2dskxkib31rba64w8iblxl185x-libev-4.33/lib/libev.so.4
#12 0x000000000040c269 in session_run (ps=0x7ebcf0) at ../src/picom.c:2325
#13 main (argc=3, argv=0x7fffffffd228) at ../src/picom.c:2426

jluttine · 2020-04-18T10:23:21Z

Seems to be a bit random what the backtrace is exactly.

absolutelynothelix · 2020-04-19T12:26:59Z

in both cases these stack traces are not related to the picom. the first one ends in i965_dri.so, which is a driver for intel gpus, and the second one ends in libGLX_mesa.so, which is a glx library. so i guess there is a bug in these drivers (or only in a libGLX_mesa.so, since the first stack trace also goes through it).

similar stack traces: #205 (solved with a system update), #265 (unsolved)

yshui · 2020-04-19T14:30:25Z

@jluttine Does --experimental-backends have the same problem?

jluttine · 2020-04-19T15:30:13Z

@yshui Doesn't seem to have! I ran picom --config=config/picom.conf --experimental-backends with the same config file. With --experimental-backends it doesn't segfault. Without it, it (almost?) always segfaults.

yshui · 2020-04-19T22:33:15Z

@jluttine I remember fixing a similar problem for the experimental backends. I will see what can be done.

yshui · 2020-04-20T04:35:46Z

@jluttine I applied the same fix i used for the experimental backends. Can you git pull and try it?

jluttine · 2020-04-20T06:29:12Z

@yshui Unfortunately 701eb0a didn't fix the segfault. Still segfaulting as before. But still works with --experimental-backends.

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>

yshui · 2020-04-20T18:25:15Z

@jluttine should be fixed now. can you try again?

jluttine · 2020-04-21T04:40:48Z

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

yshui · 2020-04-21T18:29:36Z

@jluttine It was a picom bug. We kept some pointers to data freed during reset.

l29ah · 2021-10-22T04:31:50Z

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

What can be done about this?

l29ah · 2021-10-22T04:40:17Z

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.

liskin · 2021-11-01T16:00:51Z

519bf85 is probably all right, it just makes glx_find_fbconfig slower, but more correct. The real problem is 754531e, which causes glx_find_fbconfig to be called whenever a window is moved/resized. So if you have dozens of windows and xmonad moves them all around, this results in a massive slowdown.

(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.)

liskin · 2024-01-25T14:05:36Z

@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… :-)

l29ah · 2024-01-25T14:09:22Z

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

yshui · 2024-01-25T14:30:40Z

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

yshui · 2024-02-10T14:34:58Z

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

yshui · 2024-02-10T14:37:43Z

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>

liskin · 2024-03-01T16:54:17Z

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

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!

yshui closed this as completed in 701eb0a Apr 20, 2020

yshui reopened this Apr 20, 2020

yshui added a commit that referenced this issue Apr 20, 2020

opengl: clear fbcfg in free_paint_glx

754531e

So we don't reuse the old, freed fbcfg across reset. Related: #381 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>

yshui added a commit that referenced this issue Apr 20, 2020

render: move argb_fbconfig to struct session

d1f4969

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 closed this as completed Apr 21, 2020

yshui added this to the v8 milestone Apr 21, 2020

yshui added the bug label Apr 21, 2020

liskin mentioned this issue Jan 31, 2022

if use picom,xmonad does not display emacs border correctly after emacs update.（Update: emacs upstream fixed) xmonad/xmonad#372

Closed

3 tasks

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Reloading picom crashes #381

Reloading picom crashes #381

jluttine commented Apr 17, 2020

jluttine commented Apr 17, 2020 •

edited

Loading

yshui commented Apr 17, 2020 •

edited

Loading

jluttine commented Apr 17, 2020

yshui commented Apr 17, 2020 •

edited

Loading

jluttine commented Apr 18, 2020

jluttine commented Apr 18, 2020

jluttine commented Apr 18, 2020

absolutelynothelix commented Apr 19, 2020

yshui commented Apr 19, 2020

jluttine commented Apr 19, 2020

yshui commented Apr 19, 2020

yshui commented Apr 20, 2020

jluttine commented Apr 20, 2020

yshui commented Apr 20, 2020

jluttine commented Apr 21, 2020

yshui commented Apr 21, 2020

l29ah commented Oct 22, 2021

l29ah commented Oct 22, 2021

liskin commented Nov 1, 2021

liskin commented Jan 25, 2024

l29ah commented Jan 25, 2024

yshui commented Jan 25, 2024

yshui commented Feb 10, 2024

yshui commented Feb 10, 2024

liskin commented Mar 1, 2024

Reloading picom crashes #381

Reloading picom crashes #381

Comments

jluttine commented Apr 17, 2020

Platform

GPU, drivers, and screen setup

Environment

picom version

Configuration:

Steps of reproduction

Expected behavior

Current Behavior

Stack trace

Other details

jluttine commented Apr 17, 2020 • edited Loading

yshui commented Apr 17, 2020 • edited Loading

jluttine commented Apr 17, 2020

yshui commented Apr 17, 2020 • edited Loading

jluttine commented Apr 18, 2020

jluttine commented Apr 18, 2020

jluttine commented Apr 18, 2020

absolutelynothelix commented Apr 19, 2020

yshui commented Apr 19, 2020

jluttine commented Apr 19, 2020

yshui commented Apr 19, 2020

yshui commented Apr 20, 2020

jluttine commented Apr 20, 2020

yshui commented Apr 20, 2020

jluttine commented Apr 21, 2020

yshui commented Apr 21, 2020

l29ah commented Oct 22, 2021

l29ah commented Oct 22, 2021

liskin commented Nov 1, 2021

liskin commented Jan 25, 2024

l29ah commented Jan 25, 2024

yshui commented Jan 25, 2024

yshui commented Feb 10, 2024

yshui commented Feb 10, 2024

liskin commented Mar 1, 2024

jluttine commented Apr 17, 2020 •

edited

Loading

yshui commented Apr 17, 2020 •

edited

Loading

yshui commented Apr 17, 2020 •

edited

Loading