Picom crash due polkit windows when xrender is set with experimental-backends and shadows

MR-Diamond commented 3 years ago

Platform

Manjaro 64 bit

GPU, drivers, and screen setup

intel i915 - OpenGL: renderer: Mesa DRI Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 21.0.3

Environment

Xfce 4.16 (wirh CSD enabled)

picom version

picom vgit-dac85

Steps of reproduction

I notice that when a polkit window (the one in which I have to insert sudo password - eg in timeshift, or in sublime text while editing and save a file owned by root or simply by executing pkexec which trigger a polkit window ) appears and I type in the sudo pasword and such window is closed, Picom will always crash, is always repdoducible.

The tests:

picom --backend glx -c -b : no crash with shadows when polkit window is present picom --backend xrender -c -b : no crash with shadows when polkit window is present picom --experimental-backends --backend xrender -c -b : crash with shadows when when polkit window is present picom --experimental-backends --backend glx -c -b : no crash with shadows when polkit window is present

I tried to exclude polkit-agent-helper-1 as well polkit-gnome-authentication-agent-1 to have shadows (shadow-exclude) but these polkit windows still shows shadows and cause crash of picom in such combination: experimental-backends and xrender.

I will be glad to provide more information about (eg how to use gdb) to catch a detailed cause of the crash.

MR-Diamond commented 3 years ago

I've found an odd thing; I summarize: the crash occurs when Picom is using xrender experimental backend with shadows enabled, and when on the screen there is the polkit window (after that I enter the sudo password, so when the polkit window disappear); in the meantine I tried by tweaking and indicating (by using the --config flag) a config file, to see if there would be some option which could be the culprit or if there could be some other that could be helpful, and very oddly (repeated various time) seems that the described crash occurs if i set vsync = true; - as I comment this #vsync = true; the crash with polkit and shadows enabled no longer occurs, but the downside is that without vsync = true; I experience bad tearing when scrolling in Firefox.

The config file which I'm using:

backend = "xrender";
use-damage = true;
vsync = true;
shadow = true;
shadow-radius = 22;
shadow-offset-x = -20;
shadow-offset-y = -15;
shadow-opacity = 0.6;
shadow-exclude = [
"_GTK_FRAME_EXTENTS@:c",
"name *= 'conky'",
"name *= 'Firefox'"
];
fading = true;
fade-delta = 3;
fade-in-step = 0.03;
fade-out-step = 0.03;
no-fading-openclose = false;
fade-exclude = [];
wintypes:
{

  tooltip = { fade = true; shadow = false; opacity = 0.98; focus = true; full-shadow = false; };
  notify = { opacity = 1; }
  dock = { shadow = true; }
  dnd = { shadow = false; }
  popup_menu = { opacity = 1; shadow = true; }
  dropdown_menu = { opacity = 1; }
};

MR-Diamond commented 3 years ago

However seems that I found out how to properly exclude polkit windows from shadows: using xprop I get the WM_NAME(STRING) = "Authenticate", so I put "name = 'Authenticate'", in the "shadow-exclude" section; however is just a workaround (to be accurate: by excluding it in this way, Picom no longer crash due polkit) and I can confirm anyway all that I observed, which is always reproducible.

yshui commented 3 years ago

Hi, can you get a stack trace of the crash? Thanks

MR-Diamond commented 3 years ago

Output of coredumpctl gdb after the crash:

       PID: 451232 (picom)
           UID: 1000 (dave)
           GID: 1000 (dave)
        Signal: 11 (SEGV)
     Timestamp: Sat 2021-06-05 15:23:13 CEST (3min 14s ago)
  Command Line: /usr/bin/picom --experimental-backends --config /home/dave/.config/compton.conf -b
    Executable: /usr/bin/picom
 Control Group: /system.slice/picom-comp.service
          Unit: picom-comp.service
         Slice: system.slice
       Boot ID: 529a0e7880fe4bf08476d0f7f31205d3
    Machine ID: 010d6142e6394859bc926ec7401be8d5
      Hostname: hal9000
       Storage: /var/lib/systemd/coredump/core.picom.1000.529a0e7880fe4bf08476d0f7f31205d3.451232.1622899393000000.zst
       Message: Process 451232 (picom) of user 1000 dumped core.

                Stack trace of thread 451232:
                #0  0x000056190af5c98a n/a (picom + 0x3098a)
                #1  0x000056190af5c0af n/a (picom + 0x300af)
                #2  0x000056190af60b36 n/a (picom + 0x34b36)
                #3  0x000056190af37f99 n/a (picom + 0xbf99)
                #4  0x00007f22defa0033 ev_invoke_pending (libev.so.4 + 0x5033)
                #5  0x00007f22defa3902 ev_run (libev.so.4 + 0x8902)
                #6  0x000056190af363e1 n/a (picom + 0xa3e1)
                #7  0x00007f22dea03b25 __libc_start_main (libc.so.6 + 0x27b25)
                #8  0x000056190af374ce n/a (picom + 0xb4ce)

Failed to invoke gdb: No such file or directory

backtrace:

bash: backtrace: command not found

I attach the coredump file.

core.picom.1000.529a0e7880fe4bf08476d0f7f31205d3.451232.1622899393000000.zip

tryone144 commented 3 years ago

@MR-Diamond Thanks, but can you please rebuild picom with debug symbols and upload the new coredump?

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

And please upload the executable that generated the coredump as well.

Failed to invoke gdb: No such file or directory

It looks as if you don't have gdb installed.

MR-Diamond commented 3 years ago

I've built the actual vgit-86c54 version (with debug enabled as you indicated me), and I had vgit-dac85. I built it and doesn't crash. So, maybe something has been fixed in the meanhile. Now that I know how to build the debug version, in future if/when needed, I will follow your advice.

yshui / picom