Open wxl opened 3 years ago
I don't use lxqt-admin-user
(or similar apps) but, in the case of a crash, a backtrace is needed and appreciated — unless another dev can reproduce it and find the trace himself.
Like I said, there are other actions that lead to this behavior. Heck, I just did a pkexec muon
and got it to go, forcing lxqt-policykit-agent
to respawn. I'll see if I can't get this traced.
Like I said, there are other actions that lead to this behavior
Coredumps are in /var/lib/systemd/coredump
and lxqt-policykit's backtrace can be extracted from there, regardless of how the crash happened.
Right-o, though I suspect you probably want all the debug symbols installed. I'm almost there.
I suspect you probably want all the debug symbols
Just what comes after where
could be useful:
coredumpctl gdb APP_NAME
where
Well, Ubuntu has to be different, you know. We use Apport which apparently conflicts with systemd-coredumpctl
so that explains why there's nothing in the folder you mentioned. Unfortunately, I got no information from coredumpctl gdb
but I did install a bunch of symbols. Unfortunately, I'm not having much luck. gdb
seems to exit when the crash happens. Here's what I had before installing the symbols. I will work on this more tomorrow.
@wxl This is just a blind guess, but can you give lxqt/lxqt-policykit#106 a try? It may help.
Hm... actually the PR may definitely help... as in the polkitqt1's Session destructor:
Session::~Session()
{
if (d->polkitAgentSession)
g_object_unref(d->polkitAgentSession);
delete d;
}
and in the code after emitting completed
void Session::Private::completed(PolkitAgentSession *s, gboolean gained_authorization, gpointer user_data)
{
qDebug() << "COMPLETED";
Session *session = (Session *)user_data;
Q_EMIT(session)->completed(gained_authorization);
//free session here as polkit documentation asks
g_object_unref(session->d->polkitAgentSession);
session->d->polkitAgentSession = nullptr;
}
In the destructor the polkitAgentSession
is not set to nullptr
... so without #106, we end in g_object_unref
-ing twice on the same object.
If anything crashes, I save its backtrace in a file to check it later. About a month ago, I intentionally entered a wrong password in lxqt-policykit's dialog several times, while working on pcmanfm-qt's admin mode. That resulted in a crash in lxqt-policykit (no debug symbol):
#0 0x00007efeb21e1435 in QWidget::hide() () at /usr/lib/libQt5Widgets.so.5
#1 0x000055c69f684603 in ()
#2 0x00007efeb1727e10 in () at /usr/lib/libQt5Core.so.5
#3 0x00007efeb26f74f0 in PolkitQt1::Agent::Session::completed(bool) () at /usr/lib/libpolkit-qt5-agent-1.so.1
#4 0x00007efeb26f7cf2 in PolkitQt1::Agent::Session::Private::completed(_PolkitAgentSession*, int, void*) ()
at /usr/lib/libpolkit-qt5-agent-1.so.1
#5 0x00007efeb0c97052 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#6 0x00007efeb0cbf9c5 in () at /usr/lib/libgobject-2.0.so.0
#7 0x00007efeb0cb359d in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#8 0x00007efeb0cb3d25 in g_signal_emit_by_name () at /usr/lib/libgobject-2.0.so.0
#9 0x00007efeb0aa3bff in () at /usr/lib/libpolkit-agent-1.so.0
#10 0x00007efeb0d2ea84 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#11 0x00007efeb0d829b1 in () at /usr/lib/libglib-2.0.so.0
#12 0x00007efeb0d2d2b1 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#13 0x00007efeb17496e1 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib/libQt5Core.so.5
#14 0x00007efeb16ef3fc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#15 0x00007efeb16f7894 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
#16 0x000055c69f6830f3 in ()
#17 0x00007efeb10bb152 in __libc_start_main () at /usr/lib/libc.so.6
#18 0x000055c69f68318e in _start ()
@palinek's patch may be related to and fix it, although it isn't something I can reproduce.
So I did get this to break once before adding all the symbol files, after which I seemed to have more problems with gdb than anything. Anyways. Here's a trace of the running lxqt-policykit-agent
. It looks like the crash occurs right after the g_object_unref
which perhaps suggests @palinek is right. I'll get to testing that out sometime today hopefully.
#0 0x00007f463de4ebc1 in g_type_check_instance_is_fundamentally_a () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1 0x00007f463de32c29 in g_object_unref () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2 0x00007f463f8c763d in PolkitQt1::Agent::Session::Private::completed(_PolkitAgentSession*, int, void*) () from /lib/x86_64-linux-gnu/libpolkit-qt5-agent-1.so.1
#3 0x00007f463de2d8fa in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4 0x00007f463de404b3 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5 0x00007f463de46c41 in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007f463de46fcf in g_signal_emit_by_name () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007f463e8e9266 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#8 0x00007f463f58c6b2 in QDialog::finished(int) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9 0x00007f463e8e92a0 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007f463f522e58 in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x00007f463e8e92a0 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007f463f47d5d6 in QAbstractButton::clicked(bool) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x00007f463f47df9e in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x00007f463f47f26a in QAbstractButton::click() () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007f463f58da4c in QDialog::keyPressEvent(QKeyEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007f463f3cfc3f in QWidget::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x00007f463f38e193 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x00007f463f3956df in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x00007f463e8b18fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007f463f3ea9d8 in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x00007f463f38e193 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#22 0x00007f463e8b18fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007f463ec906da in QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#24 0x00007f463ec69e4c in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#25 0x00007f463a8ffe7e in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#26 0x00007f463dec769b in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007f463dec7948 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x00007f463dec7a13 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x00007f463e90ad33 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x00007f463e8b01db in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x00007f463e8b86f4 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#32 0x000055e884f30fab in main (argc=<optimized out>, argv=<optimized out>) at ./src/main.cpp:58
This was found when trying to add a second user with lxqt-admin-user in the sudo group and then trying to use it again to remove the group membership. It appears that during this process, lxqt-policykit crashes, causing the change to fail.
Expected Behavior
lxqt-policykit doesn't crash.
Current Behavior
lxqt-policykit crashes. Example message (note this is a little old, but I've tested it with even earlier version as well as git master and the result is the same, with version numbers changed, obviously):
Steps to Reproduce (for bugs)
System Information
I'm just going to clip all this because it seems to affect versions new and old, so the version information really doesn't seem to matter at all. I did verify this in the Lubuntu CI builds of Git master, so I'm confident the problem still exists.
That said, I only checked Lubuntu systems. It's possible there is some underlying issue here that may be specific to our project. Using pkexec (but not sudo) seems to fail similarly as lxqt-admin-user.
Original bug here BTW.