Thunderbird 3.0 freezes when sending non-tiny attachments - nsSocketTransportService is at fault

RESOLVED INVALID

Status

()

--
critical
RESOLVED INVALID
9 years ago
8 years ago

People

(Reporter: carlos.lst, Unassigned)

Tracking

({hang})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needs protocol log])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Build Identifier: 

Hello,

I'm running a packaged version of Thunderbird 3.0 for Ubuntu Karmic (it's rc3, not the final, which I haven't been able to find). I'm seeing a problem where TB freezes when trying to send an email with attachments if these are bigger than approximately 20 kb. a 7 kb attachment seems to go through every time, a 500 kb attachment makes tb freeze every time. This doesn't seem to be related to file type.

I have used safe mode with no success. Also, other versions available for ubuntu users (daily builds) have the same problem.

All my accounts are on IMAP.

Reproducible: Always

Steps to Reproduce:
1. Create a new email
2. Attach a non-tiny file
3. Press send

Actual Results:  
Thunderbird freezes either when sending the file or when copying to the sent folder.

Expected Results:  
The email should be sent and copied to the sent folder successfully.
(Reporter)

Comment 1

9 years ago
Created attachment 417933 [details]
Debug Info

This is some debug info I got with gdb. Notice the program doesn't actually crash, so when it froze I did ctrl-c in gdb and got the attached info.

Comment 2

9 years ago
Thanks, i think the socket transport service is at fault:

Thread 22 (Thread 0x7fa0f00ff910 (LWP 21971)):
#0  poll () from /lib/libc.so.6
#1  ?? () from /usr/lib/libnspr4.so
#2  ?? () from /usr/lib/libnspr4.so
#3  PR_SetPollableEvent () from /usr/lib/libnspr4.so

#4  nsSocketTransportService::OnDispatchedEvent (this=0x7fa0f0576000, thread=<value optimized out>)
    at nsSocketTransportService2.cpp:520
#5  nsThread::PutEvent (this=0x7fa0f5b533a0, event=<value optimized out>) at nsThread.cpp:371
#6  nsSocketTransportService::Dispatch (this=0x7fa0f0576000, event=0x7fa0d82103a0, flags=0) at nsSocketTransportService2.cpp:122
#7  nsAStreamCopier::PostContinuationEvent_Locked (this=0x7fa0d8210390) at nsStreamUtils.cpp:403
#8  nsAStreamCopier::PostContinuationEvent (this=0x7fa0d8210390) at nsStreamUtils.cpp:394
#9  nsAStreamCopier::OnOutputStreamReady (this=0x7fa0f00feb70, sink=0x1) at nsStreamUtils.cpp:364
#10 nsSocketOutputStream::OnSocketReady (this=0x7fa0d7b8f028, condition=0) at nsSocketTransport2.cpp:515
#11 nsSocketTransport::OnSocketReady (this=0x7fa0d7b8eed0, fd=0x7fa0d8476460, outFlags=2) at nsSocketTransport2.cpp:1512
#12 nsSocketTransportService::DoPollIteration (this=0x7fa0f0576000, wait=<value optimized out>) at nsSocketTransportService2.cpp:686
#13 nsSocketTransportService::OnProcessNextEvent (this=0x7fa0f0576000, thread=0x7fa0f5b533a0, mayWait=0, depth=4294967295)
    at nsSocketTransportService2.cpp:535
#14 nsThread::ProcessNextEvent (this=0x7fa0f5b533a0, mayWait=0, result=0x7fa0f00fee9c) at nsThread.cpp:508
#15 NS_ProcessPendingEvents_P (thread=0x7fa0f5b533a0, timeout=4294967295) at nsThreadUtils.cpp:200
#16 nsSocketTransportService::Run (this=0x7fa0f0576000) at nsSocketTransportService2.cpp:571

Thread 1 (Thread 0x7fa10082c800 (LWP 21970)):
#0  __lll_lock_wait () from /lib/libpthread.so.0
#1  _L_lock_1173 () from /lib/libpthread.so.0
#2  pthread_mutex_lock () from /lib/libpthread.so.0
#3  PR_Lock () from /usr/lib/libnspr4.so
#4  nsAutoLock (this=0x7fa0f0576000) at ../../../dist/include/xpcom/nsAutoLock.h:219
#5  nsSocketTransportService::GetThreadSafely (this=0x7fa0f0576000) at nsSocketTransportService2.cpp:109
#6  nsSocketTransportService::Dispatch (this=0x7fa0f0576000, event=0x7fa0dfc02090, flags=0) at nsSocketTransportService2.cpp:120
---Type <return> to continue, or q <return> to quit---
#7  nsAStreamCopier::PostContinuationEvent_Locked (this=0x7fa0dfc02080) at nsStreamUtils.cpp:403
#8  nsAStreamCopier::PostContinuationEvent (this=0x7fa0dfc02080) at nsStreamUtils.cpp:394
#9  nsAStreamCopier::Start (source=<value optimized out>, sink=0x7fa0db8e9d60, target=0x7fa0f0576008, mode=<value optimized out>, 
    chunkSize=4096, callback=0, closure=0x0) at nsStreamUtils.cpp:285
#10 NS_AsyncCopy (source=<value optimized out>, sink=0x7fa0db8e9d60, target=0x7fa0f0576008, mode=<value optimized out>, chunkSize=4096, callback=0, 
    closure=0x0) at nsStreamUtils.cpp:543
#11 nsSocketTransport::OpenInputStream (this=0x7fa0d66ef880, flags=1, segsize=4096, segcount=16, result=0x7fa0ea4e7050)
    at nsSocketTransport2.cpp:1671
Keywords: hang
Summary: Thunderbird 3.0 freezes when sending non-tiny attachments → Thunderbird 3.0 freezes when sending non-tiny attachments - nsSocketTransportService
Timeless should we move that to nspr ?

Comment 4

9 years ago
Just a note, the build was mine and it was labeled RC3 build1 which is the same as the final release code.  If that helps any.

Comment 5

9 years ago
no, nspr is a victim. the bug is at necko or the necko caller.

someone has to dig through the stacks and figure out who is holding the locks and who is waiting and how the protocol is broken. it's probably a necko bug, so you could move it to necko.

Updated

9 years ago
Severity: normal → critical
Component: General → Networking
Product: Thunderbird → Core
QA Contact: general → networking

Comment 6

9 years ago
I can also confirm this bug in Windows 7 (build 7100), all resources are effectively consumed while trying to send non-tiny, but also non-huge (in the 300K range) attachments.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

CPU usage is pegged at 100%, all apps become unusably slow, Windows occasionally reports TBird is not responding, however leaving it alone it will continue to work, you just can't do anything else.

Machine is P4 3Ghz, 2GB, etc... enough to run a mail client. Antivirus removed for confirmation... still a problem.
> Platform: x86_64

Which Tb version do you use?
32bits version(offcial build)? 64bits version(non-official yet)?
If 32bits version, your setting(such as library path) to run 32bits modules under 64bits Linux is proper? (If 32bits Fx3 works well, your problem is not this kind of issue.)

Increase mailnews.tcptimeout value via Config Editor and restart Tb.
(I don't know mail.smtpserver.smtpN.tcptimeout is usable or not.)
Still error occurs almost always?

Old firmware version of rooter can be a cause. Outbound mail scan(port scan
type, or proxy type) by ant-virus software may produce such problem. Small MTU,
too small or too large TCP Window size may also be a cause.
> http://kb.mozillazine.org/Can_not_send_large_attachments
> bug 69931
Please be careful when test with large TCP window size(bug 532348).

FYI. Tb3 side SMTP/Socket level log with timesamp may help your diagnosis.
> https://wiki.mozilla.org/MailNews:Logging
> http://www.mozilla.org/projects/netlib/http/http-debugging.html
> http://www.mozilla.org/projects/nspr/reference/html/prlog.html#25328
> (SMTP only, example for Win)
> SET NSPR_LOG_MODULES=timestamp,smtp:5
> (Socket level log too, example for Win)
> SET NSPR_LOG_MODULES=timestamp,smtp:5,nsSocketTransport:5,nsHostResolver:5

Updated

9 years ago
Whiteboard: [needs protocol log]

Comment 8

9 years ago
I am running the most current version of TB and have not seen a recurrence lately. I will document if it comes up again. You can rule out the router as I've tested with both an OpenBSD gateway and a run-of-the-mill wireless router. As I mentioned previously, this is not anti-virus related as that was removed.
(Reporter)

Comment 9

9 years ago
Hi WADA:

I am using a 64bit-version packaged by the 'daily ppa' team at Ubuntu. I just tried the last version they have available (3.0.3pre). 

I increased the value of tcptimeout to 1000 (I was guessing) to no avail. I don't know about the router problem, but I have tried connecting without the one I use (it's brand new anyways) and that didn't solve the problem. 

I don't understand your comment on TCP windows size. 

Problem persist.

Thanks.
(Reporter)

Comment 10

9 years ago
Hello,

I was wondering if there are any news on this, as the problem persists with 3.0.4. 

Thanks.

Updated

9 years ago
Attachment #417933 - Attachment mime type: application/octet-stream → text/plain
(Reporter)

Comment 11

8 years ago
Hi,

Since my last comment, I have updated my system to the latest edition of Ubuntu (10.04/Lucid), which include TB 3.0.4. The problem is now gone.

Thanks.

Comment 12

8 years ago
carlos, thanks for keeping the bug updated. thunderbird didn't change versions,  therefor closing this bug invalid. hopefully this agrees with comment 2
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Summary: Thunderbird 3.0 freezes when sending non-tiny attachments - nsSocketTransportService → Thunderbird 3.0 freezes when sending non-tiny attachments - nsSocketTransportService is at fault
Similar issue to bugs listed in dependency tree for 541367?
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=541367&hide_resolved=0

Can smaller network.tcp.sendbuffer=65536, 32768, 16384, 8192, 4096, 2048, ... be a workaround of your problem?
(Please restart after the setting change.)
You need to log in before you can comment on or make changes to this bug.