Bug 1081055

Summary: segfault / error 5 in libQtCore.so.4.8.5 (psi-plus killed by SIGSEGV)
Product: [Fedora] Fedora Reporter: Raphael Groner <projects.rg>
Component: qtAssignee: Orphan Owner <extras-orphan>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dvratil, extras-orphan, itamar, jreznik, kevin, ltinkl, pahan, rdieter, rnovacek, smparrish, than
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-26 15:42:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace
none
core_backtrace
none
dso_list
none
environ
none
event_log
none
limits
none
maps
none
open_fds
none
var_log_messages none

Description Raphael Groner 2014-03-26 14:57:10 UTC
Description of problem:
Psi+ is the development branch of Psi, the famous XMPP/Jabber client. Since I start to press some keys while the popup is active and the main window visible, a crash happens somewhere in QEventLoop, so I am unsure how to reproduce for sure.

Version-Release number of selected component (if applicable):


How reproducible:
maybe

Steps to Reproduce:
1. receive a notification popup
2. try to press any keys
3.

Actual results:
crash

Expected results:
no crash

Additional info:
see attached logs

Comment 1 Raphael Groner 2014-03-26 14:59:24 UTC
Created attachment 879029 [details]
backtrace

Comment 2 Raphael Groner 2014-03-26 15:00:01 UTC
Created attachment 879030 [details]
core_backtrace

Comment 3 Raphael Groner 2014-03-26 15:16:27 UTC
Created attachment 879037 [details]
dso_list

Comment 4 Raphael Groner 2014-03-26 15:20:42 UTC
Created attachment 879040 [details]
environ

Comment 5 Raphael Groner 2014-03-26 15:22:07 UTC
Created attachment 879041 [details]
event_log

Comment 6 Raphael Groner 2014-03-26 15:23:53 UTC
Created attachment 879042 [details]
limits

Comment 7 Raphael Groner 2014-03-26 15:24:27 UTC
Created attachment 879053 [details]
maps

Comment 8 Raphael Groner 2014-03-26 15:25:16 UTC
Created attachment 879054 [details]
open_fds

Comment 9 Raphael Groner 2014-03-26 15:26:08 UTC
Created attachment 879055 [details]
var_log_messages

Comment 10 Rex Dieter 2014-03-26 15:42:59 UTC
Looks like a genuine psi-plus crash to me, and since psi-plus isn't yet in fedora, marking CANTFIX (for now).

Thread 1 (Thread 0x7f73282568c0 (LWP 1945)):
#0  0x0000003569b97df9 in QObject::disconnect (sender=0x6918280, signal=0x6a36109 "destroyed()", signal@entry=0xa05850 "2destroyed()", receiver=receiver@entry=0x58ce9f0, method=0x4450cb9 "eventDestroyed()", method@entry=0xa26b2d "1eventDestroyed()") at kernel/qobject.cpp:2891
        method_name = {static shared_null = {ref = {_q_value = 1}, alloc = 0, size = 0, data = 0xe64898 "", array = ""}, static shared_empty = {ref = {_q_value = 22}, alloc = 0, size = 0, data = 0x3569eea798 <QByteArray::shared_empty+24> "", array = ""}, d = 0x4450ca0}
        method_arg = 0xa26b2d "1eventDestroyed()"
        membcode = <optimized out>
        method_found = false
        signal_arg = 0xa05850 "2destroyed()"
        signal_name = {static shared_null = {ref = {_q_value = 1}, alloc = 0, size = 0, data = 0xe64898 "", array = ""}, static shared_empty = {ref = {_q_value = 22}, alloc = 0, size = 0, data = 0x3569eea798 <QByteArray::shared_empty+24> "", array = ""}, d = 0x6a360f0}
        signal_found = false
        res = false
        smeta = 0x7fff8ad609b0
#1  0x000000000086feb3 in PsiDBusNotifier::readyToDie (this=this@entry=0x58ce9f0) at psidbusnotifier.cpp:406

Comment 11 Kevin Kofler 2014-03-26 22:10:56 UTC
Looks like PsiDBusNotifier::readyToDie() is being called on an already deleted PsiDBusNotifier, so the disconnect (that gets passed the no longer valid "this" pointer) crashes.

Valgrind should be able to tell you where the offending delete happens, and it should be changed to a deleteLater.

(As Rex wrote, this is almost certainly not a bug in Qt.)