Bug 554275 - [abrt] crash in thunderbird-3.0-4.fc12
[abrt] crash in thunderbird-3.0-4.fc12
Status: CLOSED DUPLICATE of bug 573602
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
: 556363 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2010-01-11 03:42 EST by Radek Vokal
Modified: 2010-03-23 14:53 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-15 09:00:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
File: backtrace (91.10 KB, text/plain)
2010-01-11 03:42 EST, Radek Vokal
no flags Details
full gdb backtrace on crash ("thread apply all backtrace" output) (71.41 KB, text/plain)
2010-01-18 17:52 EST, Sebastian Krämer
no flags Details

  None (edit)
Description Radek Vokal 2010-01-11 03:42:38 EST
abrt 1.0.3 detected a crash.

How to reproduce
1. Scroll down thru quite a long email with 10 text attachments	
2. If you're lucky, observe the crash (I didn't happen to me second time I tried that)

Attached file: backtrace
cmdline: /usr/lib64/thunderbird-3.0/thunderbird-bin
component: thunderbird
executable: /usr/lib64/thunderbird-3.0/thunderbird-bin
package: thunderbird-3.0-4.fc12
rating: 4
reason: Process was terminated by signal 11 (Segmentation fault)
Comment 1 Radek Vokal 2010-01-11 03:42:41 EST
Created attachment 382936 [details]
File: backtrace
Comment 2 Chris Campbell 2010-01-11 10:16:49 EST
#2  <signal handler called>
No symbol table info available.
#3  0x00007f513288e05d in nsSSLThread::requestRecvMsgPeek (si=0x7f51290f8400, 
    buf=0x7ffff75eabef, amount=1, flags=2, timeout=<value optimized out>)
    at /usr/include/bits/string3.h:52
        return_amount = 1
        threadLock = {<nsAutoLockBase> = {<No data fields>}, mLock = 
    0x7f5132b059d0, mLocked = 1}
        realSSLFD = <value optimized out>
#4  0x00007f513289d0ba in PSMRecv (fd=0x7f5132b648b0, 
    buf=<value optimized out>, amount=<value optimized out>, flags=2, 
    timeout=<value optimized out>)
    at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp:2029
        locker = {<No data fields>}
        socketInfo = <value optimized out>
#5  0x00007f513be2bbde in nsSocketTransport::IsAlive (this=0x7f5131a669c0, 
    at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/netwerk/base/src/nsSocketTransport2.cpp:1808
        fd = 0x7f5132b648b0
        c = 0 '\000'
        rval = <value optimized out>

Fedora Bugzappers volunteer triage team
Comment 3 Chris Campbell 2010-01-11 10:18:22 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

First of all, could we get output of the command, saved in a text file and attached to this bug:

$ rpm -qa *thunderbird* *mozilla* *flash* *plugin*

Please also install thunderbird-debuginfo.

# debuginfo-install thunderbird

Then run thunderbird inside the gdb debugger. Please do the following:

$ thunderbird -g

Stuff will appear. Ignore this until you get the gdb command prompt, then do:

(gdb) run

Now, thunderbird should start up. Use it and reproduce the crash. When thunderbird crashes, you should be back to the gdb prompt. Now do:

(gdb) thread apply all backtrace

More screens of stuff will occur. Copy all of this part to your editor of choice, such as gedit, and save it as an uncompressed file and attach it to this bug report.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance for your extra efforts.

Fedora Bugzappers volunteer triage team
Comment 4 Chris Campbell 2010-01-18 10:05:39 EST
*** Bug 556363 has been marked as a duplicate of this bug. ***
Comment 5 Sebastian Krämer 2010-01-18 17:52:17 EST
Created attachment 385273 [details]
full gdb backtrace on crash ("thread apply all backtrace" output)

Although not the original poster, I think I experienced the same bug (abrt told me so..). I tried to recreate the crash which took some time: Some random launch/quit, also reading big mails, no problem..

However, I had a hunch that it might have to do with suspending (in my case: hiberating) the machine. Maybe changed IPs or networks have their role too. I hope this backtrace provides helpful information. (The output is uncut although I'm pretty sure it provides at least /some/ superflous information, but just to make sure, you see the output of a whole day's session of TB with a hibernation+resume into another network with new router, new IP etc.)
Comment 6 Sebastian Krämer 2010-01-18 18:11:04 EST
Just a small note: I just experienced another crash. This time, there was no hibernation involved, no network change (at most an IP change, no idea).
At first glance, the backtrace looks rather similar (lots of pthread_cond_timedwait.c occurences). If wanted though, I think I can come up with mor logging material.
Comment 7 Chris Campbell 2010-01-19 09:43:47 EST
Sebastian, those are normal. FYI, if you look at:

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fffefd8a710 (LWP 16525)]

It tells us to look at Thread 0x7fffefd8a710 (LWP 16525), so:

Thread 2 (Thread 0x7fffefd8a710 (LWP 16525)):
#0  0x000000312100e6bc in __libc_send (fd=<value optimized out>, buf=<value optimized out>, n=<value optimized out>, flags=<value optimized out>) at ../sysdeps/unix/sysv/linux/x86_64/send.c:33
#1  0x0000003131826b2d in pt_Send (fd=0x7fffdd599ca0, buf=0x7fffee7d5000, amount=23, flags=0, timeout=4294967295) at ../../../mozilla/nsprpub/pr/src/pthreads/ptio.c:1931
#2  0x0000003545a17cbb in ssl_DefSend (ss=0x7fffd3727000, buf=0x7fffee7d5000 "\025\003\001", len=23, flags=0) at ssldef.c:127
#3  0x0000003545a09de1 in ssl3_SendRecord (ss=0x7fffd3727000, type=<value optimized out>, pIn=<value optimized out>, nIn=<value optimized out>, flags=<value optimized out>) at ssl3con.c:2061
#4  0x0000003545a0a16f in SSL3_SendAlert (ss=0x7fffd3727000, level=<value optimized out>, desc=close_notify) at ssl3con.c:2316
#5  0x0000003545a1b213 in ssl_SecureClose (ss=0x7fffd3727000) at sslsecur.c:1039
#6  0x00007fffe199ffd2 in nsNSSSocketInfo::CloseSocketAndDestroy (this=0x7fffd37e7e00) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp:1682
#7  0x00007fffe198ecbc in nsSSLThread::requestClose (si=0x7fffd37e7e00) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/security/manager/ssl/src/nsSSLThread.cpp:437
#8  0x00007fffe199cf21 in nsSSLIOLayerClose (fd=0x7fffdb073f10) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp:1667
#9  0x00007fffefde8a90 in nsSocketTransport::ReleaseFD_Locked (this=0x7fffcf811a10, fd=<value optimized out>)
    at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/netwerk/base/src/nsSocketTransport2.cpp:1388
#10 0x00007fffefde92b1 in nsSocketTransport::OnSocketDetached (this=0x7fffcf811a10, fd=<value optimized out>)
    at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/netwerk/base/src/nsSocketTransport2.cpp:1611
#11 0x00007fffefdec47d in nsSocketTransportService::DetachSocket (this=0x7ffff7b8a000, sock=0x7ffff7b8a0d0)
    at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:185
#12 0x00007fffefdec7cb in nsSocketTransportService::DoPollIteration (this=0x7ffff7b8a000, wait=0) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:630
#13 0x00007fffefdeca99 in nsSocketTransportService::OnProcessNextEvent (this=0x7ffff7b8a000, thread=0x7ffff7b168f0, mayWait=0, depth=<value optimized out>)
    at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:535
#14 0x000000384506d874 in nsThread::ProcessNextEvent (this=0x7ffff7b168f0, mayWait=0, result=0x7fffefd89c4c) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/xpcom/threads/nsThread.cpp:508
#15 0x000000384503e204 in NS_ProcessPendingEvents_P (thread=0x7ffff7b168f0, timeout=4294967295) at nsThreadUtils.cpp:189
#16 0x00007fffefdec5d9 in nsSocketTransportService::Run (this=0x7ffff7b8a000) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:571
#17 0x000000384506d8c9 in nsThread::ProcessNextEvent (this=0x7ffff7b168f0, mayWait=1, result=0x7fffefd89d2c) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/xpcom/threads/nsThread.cpp:521
#18 0x000000384503e170 in NS_ProcessNextEvent_P (thread=<value optimized out>, mayWait=<value optimized out>) at nsThreadUtils.cpp:236
#19 0x000000384506e08f in nsThread::ThreadFunc (arg=0x7ffff7b168f0) at /usr/src/debug/thunderbird-3.0/comm-1.9.1/mozilla/xpcom/threads/nsThread.cpp:254
#20 0x0000003131829353 in _pt_root (arg=0x7ffff7c119d0) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:228
#21 0x0000003121006a3a in start_thread (arg=<value optimized out>) at pthread_create.c:297
#22 0x00000031204de67d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#23 0x0000000000000000 in ?? ()

is the one we're interested in. I'll give the original reporter another week to submit a gdb backtrace. If he does not by then, we can go with this.

Fedora Bugzappers volunteer triage team
Comment 8 Matěj Cepl 2010-02-26 07:19:19 EST
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
Comment 9 Jan Horak 2010-03-15 09:00:27 EDT

*** This bug has been marked as a duplicate of bug 573602 ***
Comment 10 Kai Engert (:kaie) 2010-03-23 14:53:35 EDT
The gdb backtrace doesn't help, because it simply stopped at "sigpipe", which is not a crash, and should be passed on to the app.

But the earlier stack from comment 2 gives a clue where it's happening, this will now be tracked in bug 573602.

Note You need to log in before you can comment on or make changes to this bug.