picom: ../src/win.c:704: win_set_shadow: Assertion `w->flags & WIN_FLAGS_IMAGES_NONE' failed.

[Safari77]

picom crashes immediately when I change workspace in Mate 1.23.2.
xorg-x11-server-Xorg-1.20.5-7.fc30

d4e76b271acd46b0587f739776efecf48d91553f is the first bad commit
commit d4e76b271acd46b0587f739776efecf48d91553f
Author: Yuxuan Shui <[email protected]>
Date:   Mon Nov 18 22:34:05 2019 +0000

    win: delayed release of shadow image

    Previously win_set_shadow tries to release the shadow image when turning
    off shadow for a window. When shadow is turned off _immediately_ after
    it's turned on, picom won't have a chance to handle the delayed creation
    of the shadow before win_set_shadow tries to release the shadow image,
    causing a assertion failure because win_set_shadow tried to release a
    non-existing image.

    This commit makes releasing the shadow image delayed as well.

    In theory, we could check the STALE flag in win_set_shadow before
    release the image, but that duplicates the logic that is already in
    win_process_flags.

    Signed-off-by: Yuxuan Shui <[email protected]>

 src/win.c                               | 47 ++++++++++++++++++++---------
 tests/run_tests.sh                      |  1 +
 tests/testcases/issue239_3.py           |  2 ++
 tests/testcases/issue239_3_norefresh.py | 52 +++++++++++++++++++++++++++++++++
 4 files changed, 89 insertions(+), 13 deletions(-)
 create mode 100755 tests/testcases/issue239_3_norefresh.py

Platform

Fedora 30, Mate 1.23 x86_64

GPU, drivers, and screen setup

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: Radeon 550 Series (POLARIS12, DRM 3.27.0, 4.19.83+, LLVM 8.0.0) (0x699f)
    Version: 19.2.4
    Accelerated: yes
    Video memory: 4096MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 4.5
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 1705 MB, largest block: 1705 MB
    VBO free aux. memory - total: 4052 MB, largest block: 4052 MB
    Texture free memory - total: 1705 MB, largest block: 1705 MB
    Texture free aux. memory - total: 4052 MB, largest block: 4052 MB
    Renderbuffer free memory - total: 1705 MB, largest block: 1705 MB
    Renderbuffer free aux. memory - total: 4052 MB, largest block: 4052 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 4096 MB
    Total available memory: 8192 MB
    Currently available dedicated video memory: 1705 MB
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon 550 Series (POLARIS12, DRM 3.27.0, 4.19.83+, LLVM 8.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.4
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: 4.5 (Compatibility Profile) Mesa 19.2.4
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Using 3840x2160 with one display.

picom version

**Version:** vgit-42cd5

### Extensions:

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

### Misc:

* Use Overlay: Yes
* Config file used: None

### Drivers (inaccurate):

AMDGPU, Radeon  

Configuration:

picom --backend=glx --use-damage -c --vsync

Steps of reproduction

read above

[Safari77]

I don't need to switch the workspace, just pressing alt-tab to change to another mate-terminal crashes it.

[yshui]

Can you attach a --log-level=trace log?

[Safari77]

I could have attached it yesterday if I had know of that feature, -h doesn't list it.
But here it is:

[ 25/11/19 14:42:35.791 ev_handle TRACE ] event     Damage serial 0x00000bf6 window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.806 ev_handle TRACE ] event     Damage serial 0x00000bfe window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.824 ev_handle TRACE ] event     Damage serial 0x00000c06 window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.839 ev_handle TRACE ] event     Damage serial 0x00000c0e window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.839 ev_handle DEBUG ] event   FocusOut serial 0x00000c0e window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.839 ev_focus_out DEBUG ] { mode: NotifyGrab, detail: NotifyVirtual }

[ 25/11/19 14:42:35.839 handle_pending_updates DEBUG ] Delayed handling of events, entering critical section
[ 25/11/19 14:42:35.839 recheck_focus TRACE ] 0x02c00007 (0x00800103 "(null)") focused.
[ 25/11/19 14:42:35.839 handle_pending_updates DEBUG ] Exited critical section
[ 25/11/19 14:42:35.841 ev_handle DEBUG ] event CreateNoti serial 0x00000c1e window 0x0080144e "(Failed to get title)"
[ 25/11/19 14:42:35.841 add_win DEBUG ] Adding window 0x0080144e
[ 25/11/19 14:42:35.841 handle_pending_updates DEBUG ] Delayed handling of events, entering critical section
[ 25/11/19 14:42:35.841 fill_win DEBUG ] Managing window 0x0080144e
[ 25/11/19 14:42:35.841 recheck_focus TRACE ] 0x02c00007 (0x00800103 "(null)") focused.
[ 25/11/19 14:42:35.841 handle_pending_updates DEBUG ] Exited critical section
[ 25/11/19 14:42:35.857 ev_handle TRACE ] event     Damage serial 0x00000c2c window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.875 ev_handle TRACE ] event     Damage serial 0x00000c34 window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.888 ev_handle TRACE ] event     Damage serial 0x00000c3c window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.907 ev_handle TRACE ] event     Damage serial 0x00000c44 window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.922 ev_handle TRACE ] event     Damage serial 0x00000c4c window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.940 ev_handle TRACE ] event     Damage serial 0x00000c54 window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.956 ev_handle TRACE ] event     Damage serial 0x00000c5c window 0x00800103 "(Failed to get title)"
[ 25/11/19 14:42:35.967 ev_handle DEBUG ] event ClientMess serial 0x00000c64 window 0000000000 ""
[ 25/11/19 14:42:35.967 ev_handle DEBUG ] event  MapNotify serial 0x00000c64 window 0x0080144e "(Failed to get title)"
[ 25/11/19 14:42:35.967 handle_pending_updates DEBUG ] Delayed handling of events, entering critical section
[ 25/11/19 14:42:35.967 map_win_start DEBUG ] Mapping (0x0080144e "(null)")
[ 25/11/19 14:42:35.967 map_win_start TRACE ] Window size: 400x400
[ 25/11/19 14:42:35.967 win_recheck_client TRACE ] (0x0080144e): client self (override-redirected)
[ 25/11/19 14:42:35.967 win_determine_shadow DEBUG ] Determining shadow of window 0x0080144e ((null))
[ 25/11/19 14:42:35.967 win_set_shadow DEBUG ] Updating shadow property of window 0x0080144e ((null)) to 1
picom-bug: ../src/win.c:704: win_set_shadow: Assertion `w->flags & WIN_FLAGS_IMAGES_NONE' failed.

[llitz]

I have the same error happening when I try to bring rofi up. Running on nvidia drivers.

picom.conf.zip

relevant logs

[ 01/02/2020 13:27:34.802 ev_property_notify DEBUG ] { atom = WM_HINTS }
[ 01/02/2020 13:27:34.815 ev_handle DEBUG ] event CreateNoti serial 0x00004745 window 0x05600001 "(Failed to get title)"
[ 01/02/2020 13:27:34.815 add_win DEBUG ] Adding window 0x05600001
[ 01/02/2020 13:27:34.815 handle_pending_updates DEBUG ] Delayed handling of events, entering critical section
[ 01/02/2020 13:27:34.816 fill_win DEBUG ] Managing window 0x05600001
[ 01/02/2020 13:27:34.816 handle_pending_updates DEBUG ] Exited critical section
[ 01/02/2020 13:27:34.816 ev_handle TRACE ] event     Damage serial 0x00004747 window 0x03400002 "picom --log-level=trace"
[ 01/02/2020 13:27:34.830 ev_handle DEBUG ] event ConfigureN serial 0x0000477c window 0x05600001 "(Failed to get title)"
[ 01/02/2020 13:27:34.830 ev_configure_notify DEBUG ] { send_event: 494, id: 0x05600001, above: 0x05200003, override_redirect: 1 }
[ 01/02/2020 13:27:34.830 restack_above DEBUG ] Restack 0x05600001 ((null)), old_below: 0x05200003, new_below: 0x05200003
[ 01/02/2020 13:27:34.845 ev_handle DEBUG ] event  MapNotify serial 0x0000477c window 0x05600001 "(Failed to get title)"
[ 01/02/2020 13:27:34.845 ev_handle TRACE ] event     Damage serial 0x0000477c window 0x03400002 "picom --log-level=trace"
[ 01/02/2020 13:27:34.845 ev_handle TRACE ] event     Damage serial 0x0000477e window 0x05600001 "(Failed to get title)"
[ 01/02/2020 13:27:34.845 handle_pending_updates DEBUG ] Delayed handling of events, entering critical section
[ 01/02/2020 13:27:34.858 ev_handle TRACE ] event     Damage serial 0x00004788 window 0x03400002 "picom --log-level=trace"
[ 01/02/2020 13:27:34.858 map_win_start DEBUG ] Mapping (0x05600001 "(null)")
[ 01/02/2020 13:27:34.858 map_win_start TRACE ] Window size: 1280x446
[ 01/02/2020 13:27:34.858 win_recheck_client TRACE ] (0x05600001): client self (override-redirected)
[ 01/02/2020 13:27:34.859 win_determine_shadow DEBUG ] Determining shadow of window 0x05600001 ((null))
[ 01/02/2020 13:27:34.859 win_determine_shadow DEBUG ] Shadow disabled by shadow-exclude
[ 01/02/2020 13:27:34.859 win_update_frame_extents TRACE ] (0x05600001): 0, 0, 0, 0
[ 01/02/2020 13:27:34.859 win_update_leader TRACE ] (0x05600001): client 0x05600001, leader 0000000000, cache 0x05600001
[ 01/02/2020 13:27:34.859 win_update_name TRACE ] (0x05600001): client = 0x05600001, name = "rofi", ret = 1
[ 01/02/2020 13:27:34.859 win_get_class TRACE ] (0x05600001): client = 0x05600001, instance = "rofi", general = "Rofi"
[ 01/02/2020 13:27:34.859 win_determine_shadow DEBUG ] Determining shadow of window 0x05600001 (rofi)
[ 01/02/2020 13:27:34.859 win_set_shadow DEBUG ] Updating shadow property of window 0x05600001 (rofi) to 1
picom: ../picom-9999/src/win.c:704: win_set_shadow: Assertion `w->flags & WIN_FLAGS_IMAGES_NONE' failed.
[1]    1679 abort      picom --log-level=trace

[llitz]

@yshui this is something introduced on d4e76b271acd46b0587f739776efecf48d91553f

[philippludwig]

I am experiencing this issue as well, with bspwm and nvidia drivers.

Disabling the assertion does not seem to cause any harm.

[yyny]

This only appears to be an issue in the old backend. Try --experimental-backends for now.

[yshui]

Can one of you send me a coredump of this crash, along with the picom binary (built with debug info)? Thanks.

[yshui]

I think I fixed the problem. Can someone try the latest next branch and confirm?

[philippludwig]

I tested it and can confirm that it’s fixed for my case.

[llitz]

I can test it later today and confirm

[llitz]

working without issues for me so far (=

[llitz]

Actually....
I crashed twice with

picom: ../picom-9999/src/win.c:740: win_set_shadow: Assertion `w->shadow_image || (w->flags & WIN_FLAGS_SHADOW_STALE)' failed.

Rofi works now. Perhaps there can be edge cases where flags aren't set?

I have also found this message on my xconsole (didn't show up when running from the command line, weird)

x_create_picture_with_pictfmt_and_pixmap ERROR ] failed to create picture

[yshui]

@llitz how to trigger that crash?

[llitz]

@yshui still trying to figure that one out.

I had the computer idle for a couple hours and simply switching windows made it crash (after a couple hours). Whenever I restarted picom it crashed again after 30 seconds.

Can't exactly put my finger on what, trying to understand if it was some application I had open.

[yshui]

@llitz ~do you use --experimental-backends?~

[yshui]

@llitz I pushed changes that should fix this crash. Let me know if you see it again.

[llitz]

@yshui Testing the new one, I will report back tomorrow and let you know if it crashed at all.
I am not running experimental btw (=

[llitz]

@yshui it seems stable, I haven't crashed with experimental-backends or xrender so far (glx instantly freezes my system, not sure why and I am not worried about that for now).

In one specific case, I had Microsoft Teams extremely slowed down while trying to use hardware acceleration on it as well. This only happened once and in the latest build, I will keep an eye out for that.

I believe the fixes you put out are working correctly, thanks!

[yshui]

Glad to hear that

[OrionRandD]

I have a similar issue
$ picom --backend=glx --use-damage -c --vsync
picom: ../src/win.c:1644: win_update_frame_extents: Assertion `__tmp <= 0x7fffffff' failed.
Aborted

picom --version
v8.2

I don't use nvidia, but intel driver
I run debian

[tryone144]

I have a similar issue
$ picom --backend=glx --use-damage -c --vsync
picom: ../src/win.c:1644: win_update_frame_extents: Assertion `__tmp <= 0x7fffffff' failed.
Aborted

This is a different issue. One value of _NET_FRAME_EXTENTS is too large to fit into a signed integer which should not really happen.
Can you please open a new one for this? Do you have a coredump (and the picom binary) of this crash?
Do you now which window triggered this and can provide the output of xprop _NET_FRAME_EXTENTS for that window?

[OrionRandD]

I am not a programmer.
Could you tell me the commands to run in terminal to get the infos you want?

On Fri, Dec 18, 2020 at 9:03 AM Bernd Busse [e-mail]
wrote:

I have a similar issue
$ picom --backend=glx --use-damage -c --vsync
picom: ../src/win.c:1644: win_update_frame_extents: Assertion `__tmp <=
0x7fffffff' failed.
Aborted

This is a different issue. One value of _NET_FRAME_EXTENTS is too large
to fit into a signed integer which should not really happen.
Can you please open a new one for this? Do you have a coredump (and the
picom binary) of this crash?
Do you now which window triggered this and can provide the output of xprop
_NET_WM_FRAME_EXTENTS for that window?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748049342, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKOM42H76RWJN557OWLSVNAH3ANCNFSM4JQ366BA
.

[tryone144]

Could you tell me the commands to run in terminal to get the infos you want?

See this wiki section for more details. If you use systemd you should be able to get a backtrace just from coredumpctl gdb and typing bt into the gdb prompt (quit with q). I guess you have installed picom via your distribution, so the backtrace will most likely be stripped and not too helpful. You should build it yourself with debug symbols, i.e. replace --buildtype=release with --buildtype=debug.
Can you reproduce this issue right now? If so please post the output of

$ xwininfo -root -tree | grep -e '^\s*0x' | sed -re 's/^\s*(0x[0-9a-f]*)\s.*$/\1/g' | xargs -x -L 1 -I "{}" bash -c 'xprop -id {} WM_CLASS _NET_WM_NAME _NET_FRAME_EXTENTS; echo "---"' | grep -B2 -e '_NET_FRAME_EXTENTS[^:]'

somewhere. This should print the title and _NET_FRAME_EXTENTS property for each window.

[OrionRandD]

I have purged picom from debian and installed it from sources.
Now I get this error:

picom
[ 18/12/2020 10:00:00.481 open_config_file_at WARN ] This compositor has
been renamed to "picom", the old config file paths is deprecated. Please
replace the "compton"s in the path with "picom"
[ 18/12/2020 10:00:00.481 parse_config_libconfig ERROR ] Option
no-dock-shadow has been removed. Please use the wintype option shadow
of dock instead.
[ 18/12/2020 10:00:00.481 main FATAL ERROR ] Failed to create new session.

On Fri, Dec 18, 2020 at 9:28 AM Bernd Busse [e-mail]
wrote:

Could you tell me the commands to run in terminal to get the infos you
want?

See this
https://github.com/yshui/picom/wiki/Reporting-issues#get-a-stack-trace
wiki section for more details. If you use systemd you should be able to get
a backtrace just from coredumpctl gdb and typing bt into the gdb prompt
(quit with q). I guess you have installed picom via your distribution, so
the backtrace will most likely be stripped and not too helpful. You should build
it yourself https://github.com/yshui/picom#to-build with debug symbols,
i.e. replace --buildtype=release with --buildtype=debug.
Can you reproduce this issue right now? If so please post the output of

$ xwininfo -root -tree | grep -e '^s0x' | sed -re 's/^s(0x[0-9a-f])s.$/1/g' | xargs -x -L 1 -I "{}" bash -c 'xprop -id {} WM_CLASS _NET_WM_NAME _NET_FRAME_EXTENTS & echo "---"'

somewhere. This should print the title and _NET_FRAME_EXTENTS property
for each window.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748059394, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKIR5QQOEEO5PBILBZLSVNDIXANCNFSM4JQ366BA
.

[tryone144]

The option no-dock-shadow has been removed from the config file after the release of v8.2. You should replace that option with this addition to the wintypes section in your config file:

wintypes: {
  dock: { shadow = false; }
};

To be honest, I find it more interesting what the actual value of _NET_FRAME_EXTENTS is for the offending window. It must be either really large or negative.

[OrionRandD]

Now I get this
$ picom
picom: ../src/win.c:1921: win_update_frame_extents: Assertion `__tmp <=
0x7fffffff' failed.
Aborted

:(

On Fri, Dec 18, 2020 at 10:19 AM Bernd Busse [e-mail]
wrote:

The option no-dock-shadow has been removed from the config file after the
release of v8.2. You should replace that option with this addition to the
wintypes section in your config file:

wintypes: {
dock: { shadow = false; }
};

To be honest, I find it more interesting what the actual value of
_NET_FRAME_EXTENTS is for the offending window. It must be either really
large or negative.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748079993, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKKAKAUJBZFNZMEV2ZLSVNJGJANCNFSM4JQ366BA
.

[tryone144]

If you use systemd you should be able to get a backtrace just from coredumpctl gdb picom and typing bt into the gdb prompt (quit with q)

Can you try running this please?
Your window manager (or one of your applications) sets a property to an unexpected value. I need to know what window this is and what the actual property value is. Please post the output of the command I posted above.

[OrionRandD]

thx for the help.
I decided to install a compton fork ->
https://github.com/NerdyPepper/compton
And it worked.
You can close the issue

On Fri, Dec 18, 2020 at 10:58 AM Bernd Busse [e-mail]
wrote:

If you use systemd you should be able to get a backtrace just from coredumpctl
gdb picom and typing bt into the gdb prompt (quit with q)

Can you try running this please?
Your window manager (or one of your applications) sets a property to an
unexpected value. I need to know what window this is and what the actual
property value is. Please post the output of the command I posted above
https://github.com/yshui/picom/issues/270#issuecomment-748059394.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748097941, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKNPK2BW5J6ZRO4IBDDSVNNXPANCNFSM4JQ366BA
.

[yshui]

@OrionRandD that is an inactive fork, and is 1 year out of date. i'd recommend you to not use it.

we just need a little more of your help to get down to the bottom of this issue. @tryone144's instructions should be rather easy to follow. if you need more help we are happy to provide it.

[OrionRandD]

ok. How do I fix this then:
picom
[ 18/12/2020 12:23:30.871 open_config_file_at WARN ] This compositor has
been renamed to "picom", the old config file paths is deprecated. Please
replace the "compton"s in the path with "picom"
[ 18/12/2020 12:23:30.871 parse_config_libconfig ERROR ] Option
no-dock-shadow has been removed. Please use the wintype option shadow
of dock instead.
[ 18/12/2020 12:23:30.871 main FATAL ERROR ] Failed to create new session.

I have this:

$ which compton
/usr/local/bin/compton

$ which picom
/usr/local/bin/picom

On Fri, Dec 18, 2020 at 11:58 AM yshui [e-mail] wrote:

@OrionRandD https://github.com/OrionRandD that is an inactive fork, and
is 1 year out of date. i'd recommend you to not.

we just need a little more of your help to get down to the bottom of this
issue. @tryone144 https://github.com/tryone144's instructions should be
rather easy to follow. if you need more help we are happy to provide it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748129293, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKMWUZTZTXOLUERLNULSVNUY7ANCNFSM4JQ366BA
.

[yshui]

@OrionRandD just do as this message says:

Option no-dock-shadow has been removed. Please use the wintype option shadow of dock instead.

i.e. remove no-dock-shadow from your configuration file, and use dock = { shadow = false; } in the wintypes section instead.

[OrionRandD]

picom
[ 18/12/2020 12:52:32.263 open_config_file_at WARN ] This compositor has
been renamed to "picom", the old config file paths is deprecated. Please
replace the "compton"s in the path with "picom"
[ 18/12/2020 12:52:32.263 parse_config_libconfig WARN ] vsync option will
take a boolean from now on. "opengl-swc" is interpreted as "true" for
compatibility, but this will stop working soon
picom: ../src/win.c:1921: win_update_frame_extents: Assertion `__tmp <=
0x7fffffff' failed.
Aborted

More errors :(

On Fri, Dec 18, 2020 at 12:37 PM yshui [e-mail] wrote:

@OrionRandD https://github.com/OrionRandD just do as this message says:

Option no-dock-shadow has been removed. Please use the wintype option
shadow of dock instead.

i.e. remove no-dock-shadow from your configuration file.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748161172, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKIFDP2C67AKI3UN3XTSVNZKJANCNFSM4JQ366BA
.

[OrionRandD]

~ $ which compton
/usr/local/bin/compton

~ $ which picom
/usr/local/bin/picom

Please replace the "compton"s in the path with "picom"

Do I have to remove compton with
$ sudo rm /usr/local/bin/compton

???!!!

On Fri, Dec 18, 2020 at 12:54 PM Vagner Rener [e-mail] wrote:

picom
[ 18/12/2020 12:52:32.263 open_config_file_at WARN ] This compositor has
been renamed to "picom", the old config file paths is deprecated. Please
replace the "compton"s in the path with "picom"
[ 18/12/2020 12:52:32.263 parse_config_libconfig WARN ] vsync option will
take a boolean from now on. "opengl-swc" is interpreted as "true" for
compatibility, but this will stop working soon
picom: ../src/win.c:1921: win_update_frame_extents: Assertion `__tmp <=
0x7fffffff' failed.
Aborted

More errors :(

On Fri, Dec 18, 2020 at 12:37 PM yshui [e-mail] wrote:

@OrionRandD https://github.com/OrionRandD just do as this message says:

Option no-dock-shadow has been removed. Please use the wintype option
shadow of dock instead.

i.e. remove no-dock-shadow from your configuration file.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748161172, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKIFDP2C67AKI3UN3XTSVNZKJANCNFSM4JQ366BA
.

[yshui]

@OrionRandD

picom: ../src/win.c:1921: win_update_frame_extents: Assertion `__tmp <= 0x7fffffff' failed.

Yes, this is the error we are trying to investigate here, remember?

Now, can you do this for us:

If you use systemd you should be able to get a backtrace just from
coredumpctl gdb picom and typing bt into the gdb prompt (quit with q)

And can you run this as well:

xwininfo -root -tree | grep -e '^\s*0x' | sed -re 's/^\s*(0x[0-9a-f]*)\s.*$/\1/g' | xargs -x -L 1 -I "{}" bash -c 'xprop -id {} WM_CLASS _NET_WM_NAME _NET_FRAME_EXTENTS; echo "---"' | grep -B2 -e '_NET_FRAME_EXTENTS[^:]'

[OrionRandD]

$ coredumpctl gdb picom
No match found.

On Fri, Dec 18, 2020 at 1:03 PM yshui [e-mail] wrote:

@OrionRandD https://github.com/OrionRandD

picom: ../src/win.c:1921: win_update_frame_extents: Assertion `__tmp <=
0x7fffffff' failed.

Yes, this is the error we are trying to investigate here, remember?

Now, can you do this for us:

If you use systemd you should be able to get a backtrace just from
coredumpctl gdb picom and typing bt into the gdb prompt (quit with q)

And can you run this as well:

xwininfo -root -tree | grep -e '^s0x' | sed -re
's/^s(0x[0-9a-f])s.$/1/g' | xargs -x -L 1 -I "{}" bash -c 'xprop -id
{} WM_CLASS _NET_WM_NAME _NET_FRAME_EXTENTS; echo "---"' | grep -B2 -e
'_NET_FRAME_EXTENTS[^:]'

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748175717, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKKIZW44ODCPEWH4SM3SVN4NXANCNFSM4JQ366BA
.

[OrionRandD]

xwininfo -root -tree | grep -e '^s0x' | sed -re
's/^s(0x[0-9a-f])s.$/1/g' | xargs -x -L 1 -I "{}" bash -c 'xprop -id
{} WM_CLASS _NET_WM_NAME _NET_FRAME_EXTENTS; echo "---"' | grep -B2 -e
'_NET_FRAME_EXTENTS[^:]'
WM_CLASS(STRING) = "xfce4-terminal", "Xfce4-terminal"
_NET_WM_NAME(UTF8_STRING) = "Terminal - "

_NET_FRAME_EXTENTS(CARDINAL) = 0, 3, 0, 4

WM_CLASS(STRING) = "st", "St"
_NET_WM_NAME(UTF8_STRING) = "st"

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

WM_CLASS(STRING) = "st", "St"
_NET_WM_NAME(UTF8_STRING) = "vagner@cypher:: "

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

WM_CLASS(STRING) = "Navigator", "Waterfox"
_NET_WM_NAME(UTF8_STRING) = "Re: [yshui/picom] picom: ../src/win.c:704:
win_set_shadow: Assertion `w->flags & WIN_FLAGS_IMAGES_NONE' failed. (#270)

• [email protected] - Gmail - Waterfox"
  _NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0

On Fri, Dec 18, 2020 at 1:42 PM Vagner Rener [e-mail] wrote:

$ coredumpctl gdb picom
No match found.

On Fri, Dec 18, 2020 at 1:03 PM yshui [e-mail] wrote:

@OrionRandD https://github.com/OrionRandD

picom: ../src/win.c:1921: win_update_frame_extents: Assertion `__tmp <=
0x7fffffff' failed.

Yes, this is the error we are trying to investigate here, remember?

Now, can you do this for us:

If you use systemd you should be able to get a backtrace just from
coredumpctl gdb picom and typing bt into the gdb prompt (quit with q)

And can you run this as well:

xwininfo -root -tree | grep -e '^s0x' | sed -re
's/^s(0x[0-9a-f])s.$/1/g' | xargs -x -L 1 -I "{}" bash -c 'xprop -id
{} WM_CLASS _NET_WM_NAME _NET_FRAME_EXTENTS; echo "---"' | grep -B2 -e
'_NET_FRAME_EXTENTS[^:]'

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748175717, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKKIZW44ODCPEWH4SM3SVN4NXANCNFSM4JQ366BA
.

[yshui]

@OrionRandD btw, what is your window manager?

[tryone144]

WM_CLASS(STRING) = "st", "St"
_NET_WM_NAME(UTF8_STRING) = "st"
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295
---
WM_CLASS(STRING) = "st", "St"
_NET_WM_NAME(UTF8_STRING) = "vagner@cypher:: "
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

This is interesting…
Where did you get your st from? I guess you are running xfce4?

[OrionRandD]

stumpwm

On Fri, Dec 18, 2020 at 1:50 PM yshui [e-mail] wrote:

@OrionRandD https://github.com/OrionRandD btw, what is your window
manager?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748200419, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKLX5CJHUTHSSCTXDF3SVOB5TANCNFSM4JQ366BA
.

[OrionRandD]

nope. I have run that command in the xfce4-terminal.
But, st is the default for my stumpw.
I can run that inside st as well, but the result will be the same
Here it goes, using st

xwininfo -root -tree | grep -e '^s0x' | sed -re
's/^s(0x[0-9a-f])s.$/1/g' | xargs -x -L 1 -I "{}" bash -c 'xprop -id
{}
WM_CLASS _NET_WM_NAME _NET_FRAME_EXTENTS; echo "---"' | grep -B2 -e
'_NET_FRAME_EXTENTS[^:]'
WM_CLASS(STRING) = "Navigator", "Waterfox"
_NET_WM_NAME(UTF8_STRING) = "Re: [yshui/picom] picom: ../src/win.c:704:
win_set_shadow: Assertion `w->flags & WIN_FLAGS_IMAGES_NONE' failed. (#270)

• [email protected] - Gmail - Waterfox"

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0

WM_CLASS(STRING) = "emacs", "Emacs"
_NET_WM_NAME(UTF8_STRING) = "scratch – Doom Emacs"

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

WM_CLASS(STRING) = "xfce4-terminal", "Xfce4-terminal"
_NET_WM_NAME(UTF8_STRING) = "Terminal - "

_NET_FRAME_EXTENTS(CARDINAL) = 0, 3, 0, 4

WM_CLASS(STRING) = "st", "St"
_NET_WM_NAME(UTF8_STRING) = "st"

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

WM_CLASS(STRING) = "st", "St"
_NET_WM_NAME(UTF8_STRING) = "vagner@cypher:: "
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

On Fri, Dec 18, 2020 at 1:51 PM Bernd Busse [e-mail]
wrote:

WM_CLASS(STRING) = "st", "St"

_NET_WM_NAME(UTF8_STRING) = "st"

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

---

WM_CLASS(STRING) = "st", "St"

_NET_WM_NAME(UTF8_STRING) = "vagner@cypher:: "

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 4294967295

This is interesting…
Where did you get your st from? I guess you are running xfce4?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748200731, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKLM6JN5UEN4N7ARSOTSVOB77ANCNFSM4JQ366BA
.

[yshui]

likely to be a bug in stumpwm.

Not sure how should we deal with buggy window managers. Print a warning and keep going?

[OrionRandD]

not sure it is a bug in stumpwm.
Since compton works here and in xfce4 too, but picom...

On Fri, Dec 18, 2020 at 2:00 PM yshui [e-mail] wrote:

likely to be a bug in stumpwm.

Not sure how should we deal with buggy window managers. Print a warning
and keep going?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748205242, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKM46ORX5P7LWMU7UVTSVODCHANCNFSM4JQ366BA
.

[yshui]

@OrionRandD stumpwm underflowed when calculating the size of its frame, it's a bug in stumpwm.

picom is just not handling this very gracefully.

[tryone144]

likely to be a bug in stumpwm.

Not sure how should we deal with buggy window managers. Print a warning and keep going?

I guess so. I think we can ignore obviously incorrect values with a warning. It seems _NET_FRAME_EXTENTS are rather flaky with different window managers such that I would say we should not rely too hard on this property.

[OrionRandD]

I found this:
https://github.com/stumpwm/stumpwm/issues/669
But this config seems to work, see the picom line
https://github.com/lepisma/cfg/blob/master/stumpwm/.stumpwmrc
lepisma should know how to make picom plays well in stumpwm.
Seems he is a lisper - a well known hacker in de Stumpwm comunity...

On Fri, Dec 18, 2020 at 2:10 PM Bernd Busse [e-mail]
wrote:

likely to be a bug in stumpwm.

Not sure how should we deal with buggy window managers. Print a warning
and keep going?

I guess so. I think we can ignore obviously incorrect values with a
warning. It seems _NET_FRAME_EXTENTS are rather flaky with different
window managers such that I would say we should not rely too hard on this
property.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748210643, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKNYH7OFXYUILE7F73LSVOEJPANCNFSM4JQ366BA
.

[OrionRandD]

see this new info
picom --experimental-backends
[ 18/12/2020 14:17:22.374 open_config_file_at WARN ] This compositor has
been renamed to "picom", the old config file paths is deprecated. Please
replace the "compton"s in the path with "picom"
[ 18/12/2020 14:17:22.374 parse_config_libconfig WARN ] vsync option will
take a boolean from now on. "opengl-swc" is interpreted as "true" for
compatibility, but this will stop working soon
[ 18/12/2020 14:17:22.374 get_cfg WARN ] Rounded corner is only supported
on legacy backends, it will be disabled
picom: ../src/win.c:1921: win_update_frame_extents: Assertion `__tmp <=
0x7fffffff' failed.
Aborted

On Fri, Dec 18, 2020 at 2:10 PM Bernd Busse [e-mail]
wrote:

likely to be a bug in stumpwm.

Not sure how should we deal with buggy window managers. Print a warning
and keep going?

I guess so. I think we can ignore obviously incorrect values with a
warning. It seems _NET_FRAME_EXTENTS are rather flaky with different
window managers such that I would say we should not rely too hard on this
property.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748210643, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKNYH7OFXYUILE7F73LSVOEJPANCNFSM4JQ366BA
.

[yshui]

@tryone144

I would say we should not rely too hard on this property.

But it's the only source of that information?

[OrionRandD]

thx. But I will stick to the old compton here.
You can close the issue.

On Fri, Dec 18, 2020 at 2:31 PM yshui [e-mail] wrote:

@tryone144 https://github.com/tryone144

I would say we should not rely too hard on this property.

But it's the only source of that information?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748220092, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKIFXMG6CBGK5U7HQALSVOGWLANCNFSM4JQ366BA
.

[OrionRandD]

There is still something here:
https://git.jeremydormitzer.com/jdormit/dotfiles/commit/7a1b5467a9bcb6e3baf571f8cd82eef92af01b3c
but I am really tired by now...

On Fri, Dec 18, 2020 at 2:31 PM yshui [e-mail] wrote:

@tryone144 https://github.com/tryone144

I would say we should not rely too hard on this property.

But it's the only source of that information?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yshui/picom/issues/270#issuecomment-748220092, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLPRKIFXMG6CBGK5U7HQALSVOGWLANCNFSM4JQ366BA
.

[tryone144]

I would say we should not rely too hard on this property.

But it's the only source of that information?

That's true. But we should not choke on "invalid" values in my opinion. There are some wms out there that don't take

The Window Manager MUST set _NET_FRAME_EXTENTS to the extents of the window's frame.

all too literal.

@OrionRandD This is a bug with stumpwm. _NET_FRAME_EXTENTS should never take such a high (or negative) value. Older versions/forks of compton/picom don't fail hard because they don't check the validity of the returned values.
But given your scenario we might be better off just ignoring values that don't make sense instead of enforcing sensible values.