Closed Bug 535070 Opened 15 years ago Closed 8 years ago

hung 100% cpu sending large attachment, UI thread blocked on http

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: hang, Whiteboard: [has stacktrace][needs protocol log])

Attachments

(1 file)

windbg stack for hang sending large attachment
45.47 KB, text/plain
Details 
TB 3.1a1 20091204, imap, account is set to fcc sent messages to Inbox
hang sending large attachment

attached 12mb file (should be within quota limits)
send
hang

did not retry
I've seen this once with a 3.0pre build and an 8MB(?) attachment, Gmail IMAP without copying to Sent folder (done by Gmail's server). It went through 75%, then stalled completely, unresponsive GUI, needed to be terminated in the Task Manager (WinXP). I couldn't reproduce it, thus likely not of much help, but not restricted to trunk builds or Vista if it was the same thing.
> 00e4f8e0 001ba709 thunderbird!nsHttpConnectionMgr::PostEvent

That's weird - if it got stuck during an SMTP sending process, why do you have a thread about an HTTP connection? Maybe if you provide more details when it got stuck may help the diagnosis (during sending or before that when opening the connection to start with? If it's TLS/SSL/STARTTLS, such a connection may have made sense to get certificate information).
I left the computer immediately after clicking send, so I don't have any progress information based on observation. smtp is STARTTLS, not secure auth, port 587
(In reply to comment #0)
> TB 3.1a1 20091204, imap, account is set to fcc sent messages to Inbox
> hang sending large attachment

Do you intensionally set fcc to Inbox?
If you can afford to no IDLE command use in your dayly use, disable "use IDLE if server supports IDLE". Does problem still occur frequently?

Anyway, get SMTP and IMAP log with timestamp, please. (smtp:5,imap:5,timestamp)
If net work related issue is suspected, add nsSocketTransport:5,nsHostResolver:5, please.
If possible, get log with simplest environment/settings, with mail send to yoursef(big mail, so no trafiic to external is better for test), please:
  one IMAP + one SMTP, no IDLE, no periodical IMAP mail check, no Gloda,
  no auto-sync, no software update check, no RSS, ...
TB 3.0.2pre on Linux x86_64 and TB 3.0.0 on Windows XP 32 bit always hangs when sending email with attachment.
On Windows XP 32bit TB 3.0 produces an enormous number of context switches when sending an attachment (verified with Sysinternals' Process Explorer)
Process Monitor show's that TB is trying to write <userdir>/Local Settings/Temp/nsemail-6.eml which always produces a "FAST IO DISALLOWED" result. (about 10.000
Events per second)
This happens even for small attachments < 500 KB
(In reply to comment #0)
> account is set to fcc sent messages to Inbox

See bug 486947 for known problem when Sent=Inbox is intensionally set.
Even if local mail folder(POP3 account), Sent==Inbox causes contension between mail download(append data to Inbox) and sent mail copy(append data to Inbox).

(In reply to comment #5)
> TB 3.0.2pre on Linux x86_64 and TB 3.0.0 on Windows XP 32 bit always hangs when sending email with attachment.
(In reply to comment #6)
> On Windows XP 32bit TB 3.0 produces an enormous number of context switches when sending an attachment (verified with Sysinternals' Process Explorer)

Intensional Sent==Inbox case? IMAP? POP3?

(In reply to comment #6)
> Process Monitor show's that TB is trying to write <userdir>/Local
> Settings/Temp/nsemail-6.eml which always produces a "FAST IO DISALLOWED"
> result. (about 10.000  Events per second)
> This happens even for small attachments < 500 KB

Some Web pages reachable by Google search for ""FAST IO DISALLOWED".
> http://www.msfn.org/board/fast-io-disallowed-t130884.html&s=40252d1d32a03d503b3448b66b6fb32b
> http://forum.sysinternals.com/forum_posts.asp?TID=8745
> http://web.archive.org/web/20030625222552/http://www.osr.com/ntinsider/1996/fastio.htm

nsemail-6.eml is written in directory pointed by environment variable of "Temp"(at command prompt, echo %Temp%"). Is the Temp directory placed at network drive? Shared folder or something is used?

Mail sending consist of:
(19 generate mail data stream with attached data
    (writing nsemail-6.eml corresponds to this step)
(2) pass the mail data to SMPT server
(3) copy the mail data to Sent folder
Time to take for (1) can be known by "Send Later"(or "Save As Draft").
How long does "Send Later"(without auto-save, without save as draft) take in your environment?
To all problem reporters:

Is the large attachment file located on local hard disk? Or located on network drive?
Hi!

"Intensional Sent==Inbox case? IMAP? POP3?"

In my case it's POP3 and Sent!=Inbox.

"Is the large attachment file located on local hard disk? Or located on network
drive?"

Attachment file is located on local hard disk.

Regards?
Hello,

"Intensional Sent==Inbox case? IMAP? POP3?"

Here it's IMAP with Sent!= Inbox from a local folder.
Temp folder is also local.
"Send Later" work almost instantly, no delay here.

Problem still persists with new TB 3.0.1
(In reply to comment #10)
> "Intensional Sent==Inbox case? IMAP? POP3?"
> Here it's IMAP with Sent!= Inbox from a local folder.
> Temp folder is also local.
> "Send Later" work almost instantly, no delay here.

Can you get SMTP log with timestamp for sending a mail to SMTP(Send Unsent Messages) after "Send Later" for which there is no no problem?
> https://wiki.mozilla.org/MailNews:Logging
> http://www.mozilla.org/projects/nspr/reference/html/prlog.html#25328
> set nspr_log_modules=timestamp,smtp:5,imap:5
I think i found the cause.
I connected to the mail server via an OpenVPN Tunnel. 

When i connect to the server without the tunnel TB does still produce a very high system load during sending, but it doesn't hang anymore.

Thanks for the suggestions
(In reply to comment #4)
> (In reply to comment #0)
> > TB 3.1a1 20091204, imap, account is set to fcc sent messages to Inbox
> > hang sending large attachment
> 
> Do you intensionally set fcc to Inbox?

yes. my sent mail goes to Inbox

> If you can afford to no IDLE command use in your dayly use, disable "use IDLE
> if server supports IDLE". Does problem still occur frequently?

I've not seen problem again with IDLE enabled on this laptop.


xref  Bug 522986 -  deadlock copying message to IMAP sent folder
(In reply to comment #13)
> yes. my sent mail goes to Inbox
> I've not seen problem again with IDLE enabled on this laptop.
> 
> xref  Bug 522986 -  deadlock copying message to IMAP sent folder

I sounds that problem is not in "copy to sent after send" process, sounds that problem occurrs during SMTP sending.  
If deadlock like problem, it may be problem when response time nearly equals to tcptimeout. (e.g. "cancel of timeout just after normal response" and "send timeout by tcptimeout" happens at same time)

To Krzysiek, stephan.meister, Wayne Mery(bug opener):
Does different mailnews.tcptimeout reduce frequency of problem?
  10, 20, 60, 100, 180, ,,, (default is 60 or 100)
Other concern: outbound mail scanner of antivirus software.
Do you enable outbound mail scanner of anti-virus software?
If yes, what is anti-virus software and which type? (a) local mail proxy type, (b) port scan type.
Will problem disappear when "outbound mail scanner" is disabled or anti-virus software is disabled?
I have tested thunderbird 3.0 and 3.0.1. Tried to send a large attachment (12mb, some .exe). It starts to hang at "Message sent successfully" in the progressbar. After that the compose windows hangs and stays like that for about 4-8 minutes - then everything goes back to normal. As we are often sending large attachments, Thunderbird 3 is not suitable for our company. Is it possible to downgrade from Thunderbird 3.X to 2.0.0.XX?
(In reply to comment #16)
> It starts to hang at "Message sent successfully" in the progressbar.

Was the mail sent to receipient?

> After that the compose windows hangs and stays like that for about 4-8 minutes 
> - then everything goes back to normal. 

Why can your problem be same as this bug?
Is Sent IMAP folder? Or local mail folder? It's merely that copy(append=upload if IMAP) of big mail data to Sent folder takes long, isn't it?
How long does next take in your environment?
1. Compose a mail, attach big file, "Send Later",
   move mail in "Outbox" of "Local Folders" to a local mail folder
2. Copy the local mail to "Sent" folder.
(In reply to comment #17)
> (In reply to comment #16)
> > It starts to hang at "Message sent successfully" in the progressbar.
> 
> Was the mail sent to receipient?
> 
Yes, after the 4-8 minutes hangup of the compose window it is sent.
Also the compose window still remains as an uncloseable orphan, though the main window works as intened.

> > After that the compose windows hangs and stays like that for about 4-8 minutes 
> > - then everything goes back to normal. 
> 
> Why can your problem be same as this bug?
> Is Sent IMAP folder? Or local mail folder? It's merely that copy(append=upload
> if IMAP) of big mail data to Sent folder takes long, isn't it?

It is a POP mail account, Sent (and the mail account) are local folders.

> How long does next take in your environment?
> 1. Compose a mail, attach big file, "Send Later",
After clicking "Send Later" it takes about 40sec with an 12mb big attachment until the mail is saved - this is quite slow (imho it should not take longer than a few sec. This was the speed of TB 2.0.0.23) Also after this operation the orphaned compose window is there again.
>    move mail in "Outbox" of "Local Folders" to a local mail folder
Took about the same time as saving the mail
> 2. Copy the local mail to "Sent" folder.
Same as above.

The orphaned compose window shows "Compose: (no subject)" but I have entered a subject before. On Windows XP it only shows window borders and the Titlebar while there are no contents (you will see the window behind it), I am unable to move/close this window (min-/maximizing works). It does not even offer a right click menu in the taskbar.

Overall, messages with big attachments are handled very slow, be it opening, moving, sending, deleting or anything else.
This test was on Windows XP SP3 x86.
So Win XP is affected too. (Looks to me like its a general Windows issue.)

There is no problem with large attachments on Linux x86.
my tcptimeout is 100.  No antivirus installed at time of bug report.  Nor firewalls, except windows vista default firewall.
same problem, though not sent=inbox
it seems as if tb tries to take over the whole bandwidth when sending, sometimes even killing the connection
i am using thunderbird 3.0.1 with windows vista ultimate 32. yesterday i had to send several e-mails with more than 5 mb attachments. i sent pictures, each around 3 to 4 mb. with nearly every second to third e-mail thunderbird hung so that i had to kill the process. i was using smtp and also trying imap. first i was not sure if the storage of the imap account for the draft file in the background just created too much load so i switched to using a pop/smtp account. same problem.

scenario:
- windows explorer, marking the pics
- using context menu of right mouse key using "send to" then e-mail
- choosing "original size" for pics
- window opens with message having pictures as attachment
- imap account is preselected since default account, sending froze several times
- when later using pop/smtp accounts the process was the same but after the new message window with the attachment opened i switched accounts within the message window(In reply to comment #22)
> it seems as if tb tries to take over the whole bandwidth when sending,
> sometimes even killing the connection
This issue (or a similar one) also occurs here.

Ubuntu 9.10, FF 3.02 daily build from PPA (it's happened for weeks).

That is to say :
- When sending an email with a big attachment, TB is very likely to hang completely (Compiz turns the window grey).
- It is very frequent (occured twice this morning when sending four emails)
- It happens anytime while "delivering email", in the middle of the file transfer.

May I help by providing some debug logs etc. ?
To all problem reporters:

Have you already tried sufficiently large mailnews.tcptimeout value?
Have you tried "Send Later, then File/Send Unsent Messages"?
(to rule out issues while mail data generation before pass data to SMTP server)
(to rule out issue of draft auto-save to IMAP Draft just before mail sending)
(to confirm that problem occurs while mail data sending to SMTP server)

> May I help by providing some debug logs etc. ?

If NSPR log of Tb(SMTP log) with timestamp, it's useful for first screening of problem by developers of Tb.
WADA : thanks for your reply !

Here is a log : http://pastebin.com/m25acf51
(Ubuntu 9.10 AMD 64 daily build of TB 3)

This time it crashed at 5% when sending 4 pictures weighing about 2.5MB each to myself - that is to say while transfering them.

Don't hesitate to ask me for more pieces of information.
Cheers !
Same here:
WinXP Pro SP3
Thunderbird 3.01
IMAP (if that matters).
Sent != Inbox
I have the similar behaviour as that noted in Comment #12.

Sending email containing attachements to an SMTP server via an OpenVPN tunnel is extremely slow and sometimes fails completely. CPU load goes to 100% while the problem is occuring. Sending email via local LAN connection to server is okay.

This is with TB3.0.3 on a Windows XP machine, and POP/SMTP email account.
TB message indexing is turned off. Firewall is switched off.
Tried changing the mailnews.tcptimeout param to values of 20 and 500 but made no difference.
Previously TB 2.X was working fine on this machine.
(In reply to comment #26)
> Here is a log : http://pastebin.com/m25acf51

Log ends with next lines. No other log? (probably no other log)
> See http://kb.mozillazine.org/Session_logging_for_mail/news for status
> -539752448[7f13d5014040]: SMTP Send: DATA
> -539752448[7f13d5014040]: SMTP entering state: 0
> -539752448[7f13d5014040]: SMTP Response: 354 go ahead
> -539752448[7f13d5014040]: SMTP entering state: 7 (7 SEND_RCPT_RESPONSE )
> -539752448[7f13d5014040]: SMTP entering state: 8 (8 SEND_DATA_RESPONSE)

If normal end, "Send: ." follows. It's "end of data" inidicator. As SMTP logging doesn't generate log for data sending, log says "Tb is sending data" only.   
> SMTP Send: . 	
> SMTP entering state: 0	
> SMTP Response: 250 2.0.0 OK 1240292578 j34sm8506981waf.62	
> SMTP entering state: 10	
> SMTP Send: QUIT 	

Socket level log and TCP level trace may be required.
Get Socket level log with timestamp first, and check whether socket level error, retry of send etc. occurs or not, please.
> http://www.mozilla.org/projects/netlib/http/http-debugging.html
> set NSPR_LOG_MODULES=timestamp,smtp:5,nsSocketTransport:5,nsHostResolver:5
As log size becomes huge with nsSocketTransport:5, dont't attach(never paste) log data, unless your check of log completes and file size can be reduced by deleting irrelevant logs.
Hang/freeze is usually used for "Wait" type issue(CPU 0% ordinally), although "hang/freeze" is used for "non-responsiveness" issues many times in next cases.
  - Loop of instrucstions / infinite retry loop, then CPU 100%
This bug doesn't sound such phenomenon. It sounds issue of "non-responsiveness due to heavey CPU usage(100%)". It may be TCP level or IP level retry of sending data(never infinite retry loop). And, "SMTP server via an OpenVPN tunnel" is probably important keyword.

Wayne Mery(bug opener), can you change bug summary to avoid misunderstanding?
I think "CPU 100% while SMTP data sending" and "non-responsiveess while the CPU 100%" is charasteristics of this bug.
WADA : hmm, I wish I could provide you with some more debug logs, however, since I switch to Archlinux + TB 3.0.3 (I used to use Ubuntu Karmic + daily builds pre3.0.3) I didn't manage to reproduce the issue.

However, this thread was initially about a bug with the Windows version. I hope the original reporter will be able to supply more information.

I will report back if it ever happens again !
As I wrote here https://bugzilla.mozilla.org/show_bug.cgi?id=534019#c10 , it seems that this problem is becoming quite common.
bienvenu, 
Is stacktrace of any use? 
Also have protocol log comment 29 (from comment 25).  
xref bug 522986,  Bug 534019 

no rush 

(In reply to comment #30)
> 
> Wayne Mery(bug opener), can you change bug summary to avoid misunderstanding?
> I think "CPU 100% while SMTP data sending" and "non-responsiveess while the CPU
> 100%" is charasteristics of this bug.

I'm not sure this is a characteristic of my hang - I didn't check at the time
the UI thread is blocked on http - perhaps updating rss feeds, or a browser content tab?

00e4f8a4 00189286 thunderbird!nsSocketTransportService::GetThreadSafely(void)+0xf [e:\buildbot\comm-central-trunk-win32-nightly\build\mozilla\netwerk\base\src\nssockettransportservice2.cpp @ 110]
00e4f8b8 001b996e thunderbird!nsSocketTransportService::Dispatch(class nsIRunnable * event = 0x05110780, unsigned int flags = 0)+0x2f [e:\buildbot\comm-central-trunk-win32-nightly\build\mozilla\netwerk\base\src\nssockettransportservice2.cpp @ 120]
00e4f8e0 001ba709 thunderbird!nsHttpConnectionMgr::PostEvent(<function> * handler = 0x001ba677, int iparam = 0, void * vparam = 0x05110780)+0x75 [e:\buildbot\comm-central-trunk-win32-nightly\build\mozilla\netwerk\protocol\http\src\nshttpconnectionmgr.cpp @ 175]
00e4f8f0 00197d80 thunderbird!nsHttpConnectionMgr::PruneDeadConnections(void)+0xe [e:\buildbot\comm-central-trunk-win32-nightly\build\mozilla\netwerk\protocol\http\src\nshttpconnectionmgr.cpp @ 222]
00e4f950 6c9ed928 thunderbird!nsHttpHandler::Observe(class nsISupports * subject = 0x067db2b0, char * topic = 0x6ca09508 "timer-callback", wchar_t * data = 0x00000000 "")+0xe0 [e:\buildbot\comm-central-trunk-win32-nightly\build\mozilla\netwerk\protocol\http\src\nshttphandler.cpp @ 1734]
(In reply to comment #34)
> the UI thread is blocked on http - perhaps updating rss feeds, or a browser
> content tab?

wasn't there another bug where you (or asuth) recently in the last week mentioned something similar?

RSS most likely. (I don't think I had thunderbrowse installed at that time.) And with RSS update set at 10 minutes, the odds of hitting RSS activity at any given moment are fairly high. (I didn't always have it set so low - I don't recall why I changed it from 30)
dmose had this issue and we discussed it over irc and pastebin.

do you know if any of your feeds are down?
no wonder I couldn't find it. GAH!  where is raindrop when you need it??


>do you know if any of your feeds are down?

not sure I would know. How do I tell? On a few of them I have messages which don't seem relevant

Error: not well-formed
Source File: http://www.palminfocenter.com/news/5199/palminfocenter-rss-feeds/
Line: 61, Column: 90
Source Code:
      <li><a href="http://software.palminfocenter.com/platformMain.asp?platform=1&section=specials">Special Offers</a></li>
I'm not sure how you would tell, other than perhaps turning on http protocol logging and doing a get new msgs in your rss account...
Hmm, do you actually have that HTML page talking about feeds as a feed URL, or do you have some other URL that they foolishly redirected to that HTML page?
(In reply to comment #39)
> Hmm, do you actually have that HTML page talking about feeds as a feed URL, or
> do you have some other URL that they foolishly redirected to that HTML page?

in short I found plenty bad links. now deleted. While it's not known when these links went bad, if this _is_ the source of my hang, I must wonder why I could be running several months more with no other hangs?  (and my subscription list hasn't changed)

* X http://www.palminfocenter.com/news/5199/palminfocenter-rss-feeds/ (web page)
* X http://sourceforge.net/export/rss2_projdocs.php?group_id=2435  404 SourceForge.net: Inactive feed (group: 2435) 
* X http://www.nagios.org/backend/rss/newsitems.php   invalid page
* X http://feeds.everythingtreo.com/everythingtreo/ZJij   404
* X http://www.engadgetmobile.com/category/palm/  (web page)
* and perhaps a couple others that have no activity in the past year

FWIW did bz query for RSS hang - NTF except for bug 517511 and a couple crashers
I am running TB3.1.6 on Ubuntu 10.4 (9.10 up until 2/52 ago) and I have exactly the prob reported here with TB3 hanging when sending mail with any attachment larger than about 500k. My mail is IMAP and I also run Evolution mail on the same m/c - it has NO probs sending any of the attachments. I was persuaded back to TB3 by a friend and indeed its interface and general presentation is good, but the fact that Evolution doesn't give probs when sending 1 minute after TB3 has failed suggests that the prob is most defintely with TB3. I also run Outlook/XP and in investigating this problem,, TB2/XP on my laptop on the same IMAP protocol and those combinations have no problem. TB3 is unusablein this form and I will have to return to Evolution.
(In reply to comment #41)
> TB3 is unusablein this
> form and I will have to return to Evolution.

Paul: try turning off or changing your outgoing security settings. I found that without SSL on it worked fine. 

Also, I'm not entirely sure that Adobe CS4 wasn't interfering, as my problems arrived with it's installation and left with it's uninstallation. Folks with issues, have you got Adobe CS installed?
To Wayne Mery (:wsmwk), who is bug opener, for next your bug summary:
> Bug summary : hang sending large attachment

What is your definition of the phenomenon you call "hung" in this bug?
What is clear description about phenomenon what you call "hung"?
Is the your "hung" really produced by "large atachment"?

To all "me too" posters to this bug, for current next bug summay: 
> Bug summary : hang sending large attachment

What is your definition of the phenomenon you call "hung" in this bug?
What phenomenon are you talking by the "hung"?
Is the your "hung" really produced by "large atachment"?
Is your problem same as bug 538283, which is phenomenon/problem when uploading data(to SMTP server or IMAP server, or HTTP server), using SSL/TLS or StartTLS, via relatively not-so-fast connection(e.g. 128Kbps ASDL Modem instead of 100Mbps LAN)?
Please read thru and understand all bugs listed in dependency tree for the pointed bug 538283 before posting answer/comment, please.

If different, what is exact difference of your problem from bug 538283 and bugs listed in dependency tree for bug 538283?
(I've updated the summary, finally! Sorry wada)

(In reply to comment #43)
> To Wayne Mery (:wsmwk), who is bug opener, for next your bug summary:
> > Bug summary : hang sending large attachment
> 
> What is your definition of the phenomenon you call "hung" in this bug?
> What is clear description about phenomenon what you call "hung"?

solid, never ending no UI response. I don't remember how long I waited for UI to respond - but it must have been very long. Plus the time to start windbg and get stacktrace.


> Is the your "hung" really produced by "large atachment"?

Never seen the problem again, didn't attempt to reproduce, and not certain I would be able to reproduce even if I tried. I don't send attachments often enough that I could say something reproducible unless the cause made it happen 100% of time. 

Also, given the stacktrace pointing to http blocking the UI, I can't say that attachment definitely has anything to do with causing my hang.  

bug 538283 has many comments so I'm not sure I understand everything there (can we make 538283 have a whiteboard entry point to a comment which accurately and briefly summarizes the issue).  That said, I can't say if my issue is the same.

FWIW, my environment is also very stable, speedy network (at work) - to add to my previous descriptions of comment 0, comment 3, comment 13, comment 20
Summary: hang sending large attachment → hung 100% cpu sending large attachment, UI thread blocked on http
Whiteboard: [has stacktrace] → [has stacktrace][needs protocol log]
(In reply to comment #44)
> bug 538283 has many comments so I'm not sure I understand everything there
> (can we make 538283 have a whiteboard entry point to a comment which accurately and briefly summarizes the issue).

I think we need to summarize issue of that bug(and bugs in dependency tree for that bug) and need to consolidate the bugs to a crisp new bug(for issue of CPU hog and unresposiveness due to the CPU hog, only with SSL, when upload, ie. Tb is sender and server is receiver, when relatively slow connection), for such bugs, and for bugs like this bug of similar external symptom but different original issue from bug 538283.
my hang might be related to Bug 551144 checking rss feeds has perf problem freezing Thunderbird UI and high hard drive usage
I think I have resolved my problem. It was, as I suspected, something different in TB3 that was causing the problem. I applied the solution suggested here:

http://getsatisfaction.com/mozilla_messaging/topics/delivering_mail_98_thunderbird_problem#reply_3089708

I have now run 2 tests with 4mb attachments and they go through.

Simply put, an "advance" in TB3 means that some systems time out and you get the "Failed to send email" message. The author of this solution refers to "faulty" network setups. I would query this view. My router has the latest software albeit is now 6 years old.
(In reply to comment #46)
> my hang might be related to Bug 551144 checking rss feeds has perf problem
> freezing Thunderbird UI and high hard drive usage

As SMTP sending is still exists in your bug summary,
> hung 100% cpu sending large attachment, UI thread blocked on http
I guess next occur in your environment.
(1) Bug 538283 on SMTP sening using SSL
(2) Bug 538283 on IMAP upload using SSL(save sent mail copy to Sent of IMAP)
(3) Bug 551144 on RSS(http:)
(4) Bug 541001 Comment #26 on very large newsgroup
All of them causes unresponsiveness of Tb's UI.
(1) and (2) can produce unresponsiveness of many processes other than Tb.
bienvenu, iirc you recently commented in another bug about being blocked on http - but I can't find it. Do you recall which bug#?
I think bug 698882 is this issue, and one of its dependent bugs might have involved http.
(In reply to David :Bienvenu from comment #51)
> I think bug 698882 is this issue, and one of its dependent bugs might have
> involved http.

ah yes. duh.  so 649323 may be a duplicate
Depends on: 698882
(In reply to Wayne Mery (:wsmwk) from comment #50)
> being blocked on http

FYI.
If upload via http(non SSL) and problem after Tb 3.0, router's bug can produce phenomenon like CPU hog which you saw, although connection loss is usual phenmenon if router's bug is cause. In this case, reducing network.tcp.sendbuffer (default from Tb3=131072, 128KB) to less than or equall to 64KB is an effective workaround of rouer's bug.

Router's bug can affect on any of upload type data transmission from PC to server.
Please rule out router's bug case by network.tcp.sendbuffer=4096.
Does anyone still see this hang behavior in the past year?
(I hang my issue on bug 649323)
See Also: → 649323
Whiteboard: [has stacktrace][needs protocol log] → [closeme 2016-05-25][has stacktrace][needs protocol log]
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2016-05-25][has stacktrace][needs protocol log] → [has stacktrace][needs protocol log]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: