Bug 437138 - Kwin segfaults when trying to git commit using "-S" option (GPG sign)
Summary: Kwin segfaults when trying to git commit using "-S" option (GPG sign)
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: git master
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2021-05-15 08:43 UTC by Nico
Modified: 2021-05-18 12:29 UTC (History)
0 users

See Also:
Latest Commit: https://invent.kde.org/plasma/kwin/commit/a177061b51179129c769456e1af204fb66a2b83d
Version Fixed In:
dr460nf1r3: Wayland+
dr460nf1r3: Intel+
dr460nf1r3: Mesa+

Attachments
Backtrace (28.17 KB, text/x-log)
2021-05-15 12:20 UTC, Nico 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Nico 2021-05-15 08:43:38 UTC 
SUMMARY
Kwin crashes when trying to git commit with gpg signing enabled. 
Output of dmesg gives:
[   40.297234] kwin_wayland[2262]: segfault at 0 ip 00007fd439671c1e sp 00007ffd0a5caf80 error 4 cpu 0 in libkwin.so.5.22.80[7fd4395e2000+1e9000]

Commiting without signing enabled works as expected. The bug happens on both the daily compiled master version of kwin/plasma & current 5.21.90 kde-unstable version in Arch repos.

STEPS TO REPRODUCE
1. Do some changes to a git repo & commit using the "-S" option

OBSERVED RESULT
Kwin segfaults & restarts, changes weren't commited

EXPECTED RESULT
Changes are commited & Kwin doesnt segfault


SOFTWARE/OS VERSIONS
Linux: Garuda Linux (Arch) 
KDE Plasma Version: 5.22.80
KDE Frameworks Version: 5.83.0
Qt Version: 5.12.2

ADDITIONAL INFORMATION
Comment 1 Vlad Zahorodnii 2021-05-15 10:03:23 UTC 
Can you please provide the backtrace of the crash?
Comment 2 Nico 2021-05-15 12:20:21 UTC 
Created attachment 138450 [details]
Backtrace
Comment 3 Bug Janitor Service 2021-05-15 12:27:37 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/998
Comment 4 Vlad Zahorodnii 2021-05-15 12:28:04 UTC 
Nico, can you please test the patch?
Comment 5 Nico 2021-05-15 13:15:18 UTC 
Yep, compiled from the branch specified branch and commiting works now without crash.
Comment 6 Bug Janitor Service 2021-05-18 05:54:50 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1004
Comment 7 Vlad Zahorodnii 2021-05-18 12:28:45 UTC 
Git commit 2d9e2f0c701fbd57ab6b6584106b54124f52bdaf by Vlad Zahorodnii.
Committed on 18/05/2021 at 12:28.
Pushed by vladz into branch 'master'.

effects: Fix EffectWindow::shape() for X11 windows

With the introduction of scene items, the Scene::Window::bufferShape()
method was removed as it makes no sense on wayland - a window may have
several sub-surfaces, so a single region to indicate the shape of the
window won't work.

SurfaceItem::shape() returns the shape of a surface. On Wayland, it
corresponds to the rect of the wl_surface. On X11, it corresponds to the
client window rect inside the frame window, or custom shape region if
the client has set one.

On the other hand, EffectWindow::shape() wants a completely different
thing. If the window is decorated, it needs to return the rect of the
decoration. Otherwise it has to return the shape region if there's one.

In the future, the EffectWindow::shape() function must be removed as it
doesn't fit the item based design. The main reason why we have it at
all is because the x server doesn't support translucency, setting a
shape region is a (hacky) way to work around that limitation, xeyes is
a notable example.
Related: bug 435862

M  +9    -2    src/effects.cpp

https://invent.kde.org/plasma/kwin/commit/2d9e2f0c701fbd57ab6b6584106b54124f52bdaf
Comment 8 Vlad Zahorodnii 2021-05-18 12:29:15 UTC 
Git commit a177061b51179129c769456e1af204fb66a2b83d by Vlad Zahorodnii.
Committed on 18/05/2021 at 12:29.
Pushed by vladz into branch 'Plasma/5.22'.

effects: Fix EffectWindow::shape() for X11 windows

With the introduction of scene items, the Scene::Window::bufferShape()
method was removed as it makes no sense on wayland - a window may have
several sub-surfaces, so a single region to indicate the shape of the
window won't work.

SurfaceItem::shape() returns the shape of a surface. On Wayland, it
corresponds to the rect of the wl_surface. On X11, it corresponds to the
client window rect inside the frame window, or custom shape region if
the client has set one.

On the other hand, EffectWindow::shape() wants a completely different
thing. If the window is decorated, it needs to return the rect of the
decoration. Otherwise it has to return the shape region if there's one.

In the future, the EffectWindow::shape() function must be removed as it
doesn't fit the item based design. The main reason why we have it at
all is because the x server doesn't support translucency, setting a
shape region is a (hacky) way to work around that limitation, xeyes is
a notable example.
Related: bug 435862


(cherry picked from commit 2d9e2f0c701fbd57ab6b6584106b54124f52bdaf)

M  +9    -2    src/effects.cpp

https://invent.kde.org/plasma/kwin/commit/a177061b51179129c769456e1af204fb66a2b83d