| Summary: | Kwin crash after turn off "Sync to VBlank" | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Tony <jodr666> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | jodr666 |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kwin/d2bbd2a124846853748e1cb72e0e39f0cd8ae26f | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
How to
Better bactrace? I thought they were installed since i did not get the prompt to do so. Anyways here it is with debug symbols. |
||
|
Description
Tony
2019-08-18 23:33:22 UTC
Created attachment 122236 [details]
How to
Created attachment 122238 [details]
Better bactrace?
Unfortunately the backtrace is lacking debug symbols. if you are able to reproduce please install debug packages and attach a new backtrace. Created attachment 122246 [details]
I thought they were installed since i did not get the prompt to do so. Anyways here it is with debug symbols.
Backtrace is better. What we can see is the previous KWin instance crashing on tear down. @Martin This crash happens because kwin calls a pure virtual method from destructor of a base class. See https://phabricator.kde.org/D23098 The proposed patch works around the problem. (In reply to Martin Flöser from comment #5) > What we can see is the previous KWin instance crashing on tear down. kwin crashes starting from this change 1db84a2ba71657a26d2a7971eb0c35e2716742c3 Git commit d2bbd2a124846853748e1cb72e0e39f0cd8ae26f by Vlad Zagorodniy.
Committed on 31/08/2019 at 10:31.
Pushed by vladz into branch 'master'.
[x11] Fix crash during tear down
Summary:
Any call made to a virtual method in constructor/destructor of a base
class won't go to a derived class because the base class may access
uninitialized or destroyed resources.
For example, let's consider the following two classes
class Base {
public:
Base() { foo()->bar(); }
virtual ~Base() { foo()->bar(); }
virtual Foo* foo() const { return nullptr; }
};
class Derived : public Base {
public:
Derived() : mFoo(new Foo) {}
~Derived() override { delete mFoo; }
Foo* foo() const override { return mFoo; }
private:
Foo* mFoo;
};
When an instance of Derived class is created, constructors will run in
the following order:
Base()
Derived()
It's not safe to dispatch foo() method call to Derived class because
constructor of Derived hasn't initialized yet mFoo.
Same story with destructors, they'll run in the following order:
~Derived()
~Base()
It's not safe to dispatch foo() method call in the destructor of Base
class to Derived class because mFoo was deleted.
So, what does that weird C++ behavior has something to do with KWin? Well,
recently Compositor class was split into two classes - WaylandCompositor,
and X11Compositor. Some functionality from X11 doesn't make sense on
Wayland. Therefore methods that implement that stuff were "purified," i.e.
they became pure virtual methods. Unfortunately, when Compositor tears
down it may call pure virtual methods on itself. Given that those calls
cannot be dispatched to X11Compositor or WaylandCompositor, the only
choice that C++ runtime has is to throw an exception.
The fix for this very delicate problem is very simple - do not call virtual
methods from constructors and the destructor. Avoid doing that if you can!
This change moves Compositor::updateClientCompositeBlocking to X11Compositor
so it longer has to be a virtual method. Also, it kind of doesn't make sense
to keep it in base Compositor class because compositing can be blocked only
on X11.
Test Plan: KWin no longer crashes when running kwin_x11 --replace command.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: anthonyfieroni, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23098
M +5 -16 composite.cpp
M +3 -9 composite.h
M +8 -3 workspace.cpp
https://commits.kde.org/kwin/d2bbd2a124846853748e1cb72e0e39f0cd8ae26f
|