Hide Forgot
Description of problem: It crashed after X crash ... I guess the disconnect should be handled more gracefully. Version-Release number of selected component: trojita-0.7-3.fc25 Additional info: reporter: libreport-2.8.0 backtrace_rating: 4 cmdline: /usr/bin/trojita crash_function: QXcbConnection::processXcbEvents executable: /usr/bin/trojita global_pid: 32010 kernel: 4.8.0-0.rc7.git0.1.fc25.x86_64 pkg_fingerprint: 4089 D8F2 FDB1 9C98 pkg_vendor: Fedora Project runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #15 QXcbConnection::processXcbEvents at qxcbconnection.cpp:1699 #16 QObject::event at kernel/qobject.cpp:1263 #17 QApplicationPrivate::notify_helper at kernel/qapplication.cpp:3799 #18 QApplication::notify at kernel/qapplication.cpp:3556 #19 QCoreApplication::notifyInternal2 at kernel/qcoreapplication.cpp:988 #20 QCoreApplication::sendEvent at kernel/qcoreapplication.h:231 #21 QCoreApplicationPrivate::sendPostedEvents at kernel/qcoreapplication.cpp:1649 #22 QCoreApplication::sendPostedEvents at kernel/qcoreapplication.cpp:1503 #23 postEventSourceDispatch at kernel/qeventdispatcher_glib.cpp:276 #27 g_main_context_iteration at gmain.c:3988
Created attachment 1207501 [details] File: backtrace
Created attachment 1207502 [details] File: cgroup
Created attachment 1207503 [details] File: core_backtrace
Created attachment 1207504 [details] File: dso_list
Created attachment 1207505 [details] File: environ
Created attachment 1207506 [details] File: exploitable
Created attachment 1207507 [details] File: limits
Created attachment 1207508 [details] File: maps
Created attachment 1207509 [details] File: mountinfo
Created attachment 1207510 [details] File: namespaces
Created attachment 1207511 [details] File: open_fds
Created attachment 1207512 [details] File: proc_pid_status
Created attachment 1207513 [details] File: var_log_messages
Well, X is the parent process for all forked application processes. I doubt we can do anything better for X crashers.
(In reply to Raphael Groner from comment #14) > Well, X is the parent process for all forked application processes. ahem, it doesn't seem to be this way on my system: [kvolny@kvolny ~]$ ps -o ppid -C trojita PPID 1 ... and pid eins is systemd using tree view like `ps xfa`, Xorg doesn't own anything; there is lxqt-session under sddm => sddm-helper and a few processes under that, but most X applications are detached (thus collected by pid 1) > I doubt we can do anything better for X crashers. I believe there should be a way, as after X crash, I don't get fifty reports for all the applications, I get only a few for some of them (that are buggy) ... I also often run kmail via xpra, which tends to lock up with 'wrong' versions of python, and cutting its branch by forcefully killing xvfb doesn't lead to kmail crash (nor crash of any dependent akonadi and various other processes) I know it can be hard to debug as the Trojitá crash does not happen on each X crash, and I understand there is not enough manpower[*] to deal wih each and every corner case, but closing for capacity reasons is quite different from saying it can't be fixed because of the nature of things ... [*] look at me, I'm dealing with my bugzilla queue after a few months as part of "Christmas cleanup", when I had to ask my manager for a pause from the usual daily work :-(