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 ******
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
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.
Reported to Mozilla as: https://bugzilla.mozilla.org/show_bug.cgi?id=389920
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.
I have also submitted this patch to Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=389920
A revised patch has been committed to trunk upstream (see Mozilla Bugzilla).
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?
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.
Cool. Again, thanks for your help!
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.