Bug 248243 - thunderbird x86_64 segfaults sending mail
thunderbird x86_64 segfaults sending mail
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
6
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-13 23:50 EDT by Ben Caradoc-Davies
Modified: 2007-11-30 19:08 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-30 18:54:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for thunderbird to handle empty SMTP continuations (596 bytes, patch)
2007-07-28 04:09 EDT, Ben Caradoc-Davies
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 389920 None None None Never

  None (edit)
Description Ben Caradoc-Davies 2007-07-13 23:50:15 EDT
Description of problem:

thunderbird x86_64 crashes with a segfault when sending mail. i386 works fine.

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

thunderbird-1.5.0.12-1.fc6.x86_64
thunderbird-2.0.0.4-1.fc7.x86_64 

How reproducible:

Every time (with my ISP's SMTP server).

Steps to Reproduce:
1. Start thunderbird.
2. Write new email.
3. Press send.
  
Actual results:

Sending progess dialog appears. Thunderbird crashes (gdb reports segfault).

Expected results:

Mail is sent.

Additional info:

Originally observed with glibc-2.5-10.fc6.x86_64 and
thunderbird-1.5.0.12-1.fc6.x86_64. Upgrading to thunderbird-2.0.0.4-1.fc7.x86_64
 does not fix. Upgrading to glibc-2.5-18.fc6.x86_64 does not fix.
thunderbird-2.0.0.4-1.fc7.i386 works fine, so this is an x86_64-only bug.

Setting selinux permissive did not fix this, and there are no selinux udit
messages in dmesg, so this is not the selinux parentlock bug. (i386 working
precludes this).

The problem started when my ISP changed their SMTP servers, so I suspect a
change in SMTP responses has triggered this.

Here is a gdb session exibiting the crash for thunderbird-2.0.0.4-1.fc7.x86_64
(with thunderbird-debuginfo-2.0.0.4-1.fc7.x86_64):

****** gdb session ******

$ gdb /usr/lib64/thunderbird-2.0.0.4/thunderbird-bin 
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db
library "/lib64/libthread_db.so.1".

(gdb) run
Starting program: /usr/lib64/thunderbird-2.0.0.4/thunderbird-bin 
[Thread debugging using libthread_db enabled]
[New Thread 46912504146560 (LWP 2848)]
[New Thread 1084229952 (LWP 2853)]
[New Thread 1094719808 (LWP 2854)]
[New Thread 1105209664 (LWP 2855)]
[New Thread 1115699520 (LWP 2856)]
[New Thread 1126189376 (LWP 2857)]
[New Thread 1136679232 (LWP 2858)]
[New Thread 1147169088 (LWP 2859)]
[New Thread 1157658944 (LWP 2860)]
[New Thread 1168148800 (LWP 2862)]
[Thread 1168148800 (LWP 2862) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912504146560 (LWP 2848)]
0x00002aaab74f36c2 in nsSmtpProtocol::SmtpResponse (this=0x2022b90, 
    inputStream=<value optimized out>, length=<value optimized out>)
    at nsSmtpProtocol.cpp:504
504         if (m_responseText.CharAt(m_responseText.Length() - 1) != '\n')
(gdb) thread apply all bt

Thread 9 (Thread 1157658944 (LWP 2860)):
#0  0x0000003dfcc0a697 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x0000003e09621599 in PRP_NakedNotify () from /usr/lib64/libnspr4.so
#2  0x0000003e096221b9 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaab2e63b67 in nsCertVerificationThread::Run (this=0x14bf510)
    at nsCertVerificationThread.cpp:142
#4  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
#5  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 8 (Thread 1147169088 (LWP 2859)):
#0  0x0000003dfcc0a697 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x0000003e09621599 in PRP_NakedNotify () from /usr/lib64/libnspr4.so
#2  0x0000003e096221b9 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaab2e62a38 in nsSSLThread::Run (this=0x14bf110)
    at nsSSLThread.cpp:879
#4  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
#5  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
---Type <return> to continue, or q <return> to quit---
#7  0x0000000000000000 in ?? ()

Thread 7 (Thread 1136679232 (LWP 2858)):
#0  0x0000003dfcc0a697 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x0000003e09621599 in PRP_NakedNotify () from /usr/lib64/libnspr4.so
#2  0x0000003e096221b9 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaab6e94bc7 in nsIOThreadPool::ThreadFunc (
    arg=<value optimized out>) at nsIOThreadPool.cpp:254
#4  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
#5  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 6 (Thread 1126189376 (LWP 2857)):
#0  0x0000003dfcc0a697 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x0000003e09621599 in PRP_NakedNotify () from /usr/lib64/libnspr4.so
#2  0x0000003e096221b9 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaab6e94bc7 in nsIOThreadPool::ThreadFunc (
    arg=<value optimized out>) at nsIOThreadPool.cpp:254
#4  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
#5  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#6  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 5 (Thread 1115699520 (LWP 2856)):
#0  0x0000003dfcc0a697 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x0000003e09621599 in PRP_NakedNotify () from /usr/lib64/libnspr4.so
#2  0x0000003e096221b9 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaab6e94bc7 in nsIOThreadPool::ThreadFunc (
    arg=<value optimized out>) at nsIOThreadPool.cpp:254
#4  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
#5  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 4 (Thread 1105209664 (LWP 2855)):
#0  0x0000003dfcc0a697 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x0000003e09621599 in PRP_NakedNotify () from /usr/lib64/libnspr4.so
#2  0x0000003e096221b9 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaab6e94bc7 in nsIOThreadPool::ThreadFunc (
    arg=<value optimized out>) at nsIOThreadPool.cpp:254
#4  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
---Type <return> to continue, or q <return> to quit---
#5  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 3 (Thread 1094719808 (LWP 2854)):
#0  0x0000003dfcc0a697 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x0000003e09621599 in PRP_NakedNotify () from /usr/lib64/libnspr4.so
#2  0x0000003e096221b9 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaaaafd3ff1 in TimerThread::Run (this=0x647590)
    at TimerThread.cpp:318
#4  0x00002aaaaafd25e1 in nsThread::Main (arg=0x7b0410) at nsThread.cpp:118
#5  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
#6  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
#7  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
#8  0x0000000000000000 in ?? ()

Thread 2 (Thread 1084229952 (LWP 2853)):
#0  0x0000003dfa0c5d26 in poll () from /lib64/libc.so.6
#1  0x0000003e09623ae4 in PR_Poll () from /usr/lib64/libnspr4.so
#2  0x00002aaab6eb38a8 in nsSocketTransportService::Poll (
    this=<value optimized out>, interval=0x40a000c4)
    at nsSocketTransportService2.cpp:361
---Type <return> to continue, or q <return> to quit---
#3  0x00002aaab6eb3a88 in nsSocketTransportService::Run (this=0x782280)
    at nsSocketTransportService2.cpp:577
#4  0x00002aaaaafd25e1 in nsThread::Main (arg=0x783160) at nsThread.cpp:118
#5  0x0000003e096277dd in PR_JoinThread () from /usr/lib64/libnspr4.so
#6  0x0000003dfcc062f7 in start_thread () from /lib64/libpthread.so.0
#7  0x0000003dfa0ce86d in clone () from /lib64/libc.so.6
#8  0x0000000000000000 in ?? ()

Thread 1 (Thread 46912504146560 (LWP 2848)):
#0  0x00002aaab74f36c2 in nsSmtpProtocol::SmtpResponse (this=0x2022b90, 
    inputStream=<value optimized out>, length=<value optimized out>)
    at nsSmtpProtocol.cpp:504
#1  0x00002aaab74f60ef in nsSmtpProtocol::ProcessProtocolState (
    this=0x2022b90, url=<value optimized out>, inputStream=0x2027ca0, 
    sourceOffset=<value optimized out>, length=83) at nsSmtpProtocol.cpp:1619
#2  0x00002aaab74294c6 in nsMsgProtocol::OnDataAvailable (this=0x2022b90, 
    request=<value optimized out>, ctxt=<value optimized out>, 
    inStr=0x2027ca0, sourceOffset=12, count=83) at nsMsgProtocol.cpp:350
#3  0x00002aaab6e9d3d5 in nsInputStreamPump::OnStateTransfer (this=0x2027b30)
    at nsInputStreamPump.cpp:494
#4  0x00002aaab6e9d4c1 in nsInputStreamPump::OnInputStreamReady (
    this=0x2027b30, stream=0x30) at nsInputStreamPump.cpp:397
#5  0x00002aaaaafb83ef in nsInputStreamReadyEvent::EventHandler (
---Type <return> to continue, or q <return> to quit---
    plevent=<value optimized out>) at nsStreamUtils.cpp:120
#6  0x00002aaaaafcfa85 in PL_HandleEvent (self=0x7fffa8c29508) at plevent.c:688
#7  0x00002aaaaafcfc97 in PL_ProcessPendingEvents (self=0x6bcf50)
    at plevent.c:623
#8  0x00002aaaaafd0f21 in nsEventQueueImpl::ProcessPendingEvents (
    this=0x6bced0) at nsEventQueue.cpp:417
#9  0x00002aaaafd9e9d6 in event_processor_callback (
    source=<value optimized out>, condition=48, data=0x7fffa8c29508)
    at nsAppShell.cpp:67
#10 0x0000003dfe82cf64 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#11 0x0000003dfe82fd9d in g_main_context_check () from /lib64/libglib-2.0.so.0
#12 0x0000003dfe8300aa in g_main_loop_run () from /lib64/libglib-2.0.so.0
#13 0x0000003e0152dad3 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#14 0x00002aaaafd9edba in nsAppShell::Run (this=0xb5dc20) at nsAppShell.cpp:139
#15 0x00002aaab637dba2 in nsAppStartup::Run (this=0xb5dba0)
    at nsAppStartup.cpp:151
#16 0x000000000040848f in XRE_main (argc=<value optimized out>, 
    argv=<value optimized out>, aAppData=<value optimized out>)
    at nsAppRunner.cpp:2642
#17 0x0000003dfa01d8a4 in __libc_start_main () from /lib64/libc.so.6
#18 0x00000000004039b9 in _start ()
(gdb) 

****** end gdb session ******
Comment 1 Ben Caradoc-Davies 2007-07-14 00:24:37 EDT
Looking in mailnews/compose/src/nsSmtpProtocol.cpp suggests an SMTP response of
"250-", so after stripping the response code and continuation, line becomes ""
(assigned to m_responseText), so its length is zero, causing a -1 index and
segfault. I can't see why this should affect x86_64 only. Perhaps just different
timing to i386?

Or is there something bogus in the handling of cont_char?

Here is some more from gdb on the segfaulted thread:

(gdb) print m_responseText
$6 = {<nsCSubstring> = {<nsACString_internal> = {mVTable = 0x2aaaab22c0d0, 
      mData = 0x20ec6c8 "", mLength = 0, 
      mFlags = 5}, <No data fields>}, <No data fields>}
(gdb) print m_responseCode
$7 = 250
(gdb) print cont_char
$8 = 45 '-'
(gdb) print line
$9 = <value optimized out>
(gdb) print m_continuationResponse
$10 = 250
Comment 2 Ben Caradoc-Davies 2007-07-27 21:28:54 EDT
Further testing indicates that this bug is still present in
thunderbird-2.0.0.5-1.fc7.x86_64. Looks like a problem in
mailnews/compose/src/nsSmtpProtocol.cpp. I will notify upstream.
Comment 3 Ben Caradoc-Davies 2007-07-27 22:01:34 EDT
Reported to Mozilla as:
https://bugzilla.mozilla.org/show_bug.cgi?id=389920
Comment 4 Ben Caradoc-Davies 2007-07-28 04:09:55 EDT
Created attachment 160157 [details]
Patch for thunderbird to handle empty SMTP continuations

This thunderbird patch checks for empty SMTP continuation text (such as one
containing only "250-") and prevents a segfault.

I tested the patch by rebuilding thunderbird from
thunderbird-2.0.0.5-1.fc7.src.rpm with the patch included. The patched version
of thunderbird was able to send mail correctly and otherwise appears to behave
as normal.

I suspect that it is pure luck (differing memory layout) that i386 does not
segfault on this SMTP response.

This patch should be applied to thunderbird 1.5 as well as 2.0 as both are
affected by the segfault.
Comment 5 Ben Caradoc-Davies 2007-07-28 04:14:25 EDT
I have also submitted this patch to Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=389920
Comment 6 Ben Caradoc-Davies 2007-07-30 18:56:18 EDT
A revised patch has been committed to trunk upstream (see Mozilla Bugzilla).
Comment 7 Christopher Aillon 2007-08-07 10:19:32 EDT
Awesome.  Sorry for the delay in responding, but your help in fixing this is
appreciated.  It looks like this is proposed for the next release version of
Thunderbird.  Do you mind if I just wait to pull that in with that?
Comment 8 Ben Caradoc-Davies 2007-08-07 18:32:27 EDT
Waiting for upstream is fine. Although the impact is severe, there is a simple
workaround (use i386), and only users of a few SMTP servers will be affected.
Status was changed to CLOSED UPSTREAM to reflect this.

The fix is not in 2.0.0.6.
Comment 9 Christopher Aillon 2007-08-08 00:27:55 EDT
Cool.  Again, thanks for your help!
Comment 10 Ben Caradoc-Davies 2007-11-30 19:08:29 EST
I can confirm that this bug is fixed in thunderbird-2.0.0.9-1.fc7.x86_64, which
has now been distributed through Fedora 7 updates.

Thanks.

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