Thunderbird hangs while reading mails with attachments

RESOLVED INVALID

Status

Thunderbird
General
--
critical
RESOLVED INVALID
7 years ago
4 years ago

People

(Reporter: fletertre, Unassigned)

Tracking

({hang, regression})

7 Branch
x86
Windows XP
hang, regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [closeme 2012-01-11][has stack trace])

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/15.0.843.0 Safari/535.1

Steps to reproduce:

I try to read an email with attachments.
NB: It happens just after I upgraded to the 7.0.1 version. I tried to upgrade to 8.0.b3, downgrade to 7.0, 6.0.2, to install the RSS Attachment Fix1.0, to disable all extensions. None of these actions solved the problems. 


Actual results:

Thunderbird hangs and I have to kill it.
NB: In the Error console, I have this message "Warning: Use of getAttributeNodeNS() is deprecated. Use getAttributeNS() instead.
Source File: chrome://messenger/content/messenger.xul
Line: 0"


Expected results:

The email should have been displayed and I should have been able to access the file.

Comment 1

7 years ago
(In reply to fletertre from comment #0)
Please check bug 682546 comment #4 and get a stacktrace.
(Reporter)

Comment 2

7 years ago
Created attachment 572030 [details]
Stack trace

Stack trace of the freeze of Thunderbird while reading mail with attachments
(Reporter)

Comment 3

7 years ago
Is it related to Bug 692461 - Thunderbird 7.0.1 hangs when trying to attach files?
(Reporter)

Updated

7 years ago
Severity: normal → critical
Keywords: hang, regression
(In reply to fletertre from comment #3)
> Is it related to Bug 692461 - Thunderbird 7.0.1 hangs when trying to attach
> files?

The stacks are different.

Do you have the problem if your start Thunderbird in -safe-mode (see http://support.mozillamessaging.com/en-US/kb/Safe-Mode) ?
Whiteboard: [has stack trace]
(Reporter)

Comment 5

7 years ago
Yes, it doesn't change anything.

Updated

7 years ago
Duplicate of this bug: 682546

Comment 7

7 years ago
fletertre, what are your exact steps - did you open the attachments?


are we hung in windows?
001399b0 77557025 ole32!CDllHost::GetApartmentToken+0x1f7
001399c0 77527a66 ole32!DoSTApartmentCreate+0x12
Whiteboard: [has stack trace] → [closeme 2012-01-11][has stack trace]
(Reporter)

Comment 8

7 years ago
No I couldn't access them. Thunderbird froze before, as soon as I tried to access the mail. I clicked on any mail with attachements and Thunderbird froze. I couldn't even see the content of the mail. It was the same result when I tried to access Tools\Options\Attachments (as soon as I clicked on "Attachements").
Nothing I tried had any results. I had to completely reinstall Windows XP to get rid of it.

Comment 9

7 years ago
Thanks for the feedback

Sounds like the prob was something other than thunderbird
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

7 years ago
I'm afraid I disagree with you on your conclusion. 
Maybe it was caused by "something" outside the application itself but Thunderbird wasn't able to handle properly this "something", which is Thunderbird's fault. I had had the same problem a few month before with Mozilla and had to change to another browser. 
Now I can reuse both applications but I had to completely reinstall Windows. I read comment of several users who had the same problem. None of the users of Thunberbird could get rid of it without reinstalling Windows. It doesn't seem normal to me.

Comment 11

7 years ago
agree w/ fletertre - resolved/invalid for "prob was something other than thunderbird" is plain lazy.  figure out Thunderbird's dependency on whatever Windows resource/object it's hanging on, and fix it.

Comment 12

7 years ago
It's clear you both care deeply about the situation, so I'll elaborate as best as I can ...

(In reply to fletertre from comment #10)
> I'm afraid I disagree with you on your conclusion. 
> Maybe it was caused by "something" outside the application itself but
> Thunderbird wasn't able to handle properly this "something", which is
> Thunderbird's fault. 

There are many things which can affect Thunderbird (or any computer program for that matter), that Thunderbird can do nothing about, or if it can, may perhaps not be appropriate to "them" do some thing about. If someone shoots your computer with a shotgun, you don't blame the computer for being broke, you blame the shooter.  The experience of this triager, given all the information that you have presented, is that the cause of your problem is extremely likely to be some part of your computer doing something bad to other programs.

> I had had the same problem a few month before with
> Mozilla and had to change to another browser. 
> Now I can reuse both applications but I had to completely reinstall Windows.

These are further strong signals of outside interference.

> I read comment of several users who had the same problem. None of the users
> of Thunberbird could get rid of it without reinstalling Windows. It doesn't
> seem normal to me.

Indeed it is not normal. But marking the bug INVALID does not mean there is no problem, it means the fault/cause/where it should be fixed, is not mozilla/thunderbird.  You will find many such examples in the bugzilla database.

In psirois' case (bug 682546) the cause appears to be ESET, which is well known to cause problems.

THe alternative to INVALID in fletertre's case is INCOMPLETE, because you no longer have a working test case with which to reproduce the problem and give us further information. Nor would you be able to test a solution if one were offered. And the last nail in the coffin is there is insufficient information for anyone else to reproduce the problem should they desire to do so.  In short, we are not sweeping the problem "under the rug". The state of the bug is there is zero chance to progress to a solution without significantly more information from the two current reporters.

I hope that clarifies the situation. If at some point you gain additional information (one or more of stacktrace, steps to reproduce, regression window, etc) that puts the finger on thunderbird or makes it feasible to consider pursing the situation then someone will be happy to do so.
(Reporter)

Comment 13

7 years ago
It's clear I care about this problem, I spent hours trying to find a solution and the fact it can reappear one day with no explanation is something I don't like (and I'm afraid of)...
I agree with you that the cause might be external to Thunderbird or Mozilla. But they were the 2 only programs I had problems with. Thunderbird should be able to detect the problem before freezing. There's a test or exit condition missing somewhere. 
Then you're right again on the fact that I won't be able to test any fix that could be found. I couldn't wait 2 months without reading my emails!

Comment 14

7 years ago
(In reply to fletertre from comment #13)
> It's clear I care about this problem, I spent hours trying to find a
> solution and the fact it can reappear one day with no explanation is
> something I don't like (and I'm afraid of)...
> I agree with you that the cause might be external to Thunderbird or Mozilla.
> But they were the 2 only programs I had problems with. Thunderbird should be
> able to detect the problem before freezing.

Essentially, you're saying that we should be able to check if a Win32 api call will not hang and succeed before calling it. This is not possible: http://en.wikipedia.org/wiki/Halting_problem

Comment 15

7 years ago
have you isolated this Thunderbird hang to a specific Win32 api call?  if so write in some protection or escape from the block calling it, so you don't hang the entire app.  throw an error message if you need to bail from the block - better than getting into a state where user must kill the Thunderbird process.

(In reply to David :Bienvenu from comment #14)
> (In reply to fletertre from comment #13)
> > It's clear I care about this problem, I spent hours trying to find a
> > solution and the fact it can reappear one day with no explanation is
> > something I don't like (and I'm afraid of)...
> > I agree with you that the cause might be external to Thunderbird or Mozilla.
> > But they were the 2 only programs I had problems with. Thunderbird should be
> > able to detect the problem before freezing.
> 
> Essentially, you're saying that we should be able to check if a Win32 api
> call will not hang and succeed before calling it. This is not possible:
> http://en.wikipedia.org/wiki/Halting_problem
(In reply to psirois from comment #15)
> have you isolated this Thunderbird hang to a specific Win32 api call?

David merely says that resolving Halting Problem is impossible, because you looks to be asking developers to implement generic solution of Halting Problem on any program code relevant to Tb including Tb himself and Win32 api etc. 

(In reply to fletertre from comment #8)
> No I couldn't access them. Thunderbird froze before, as soon as I tried to
> access the mail. I clicked on any mail with attachements and Thunderbird
> froze. I couldn't even see the content of the mail. 

You say next.
> It was the same result when I tried to access Tools\Options\Attachments (as soon as I clicked on "Attachements").

Tb freezes forever?
When your problem of "freeze" you call occurred. did Tb use 100% CPU(loop)? Or 0% CPU(wait/hang)? Or periodical CPU power consumption(repeated "waiting for event & retry" like one)?

If last used attachment directory is network resource, and if the file server is not available any more, Tb requests the network resource, and OS(Win) searches requested file server. This takes usually long, because "non-existence" can be detected after timeout due to no response from the server.   
This case? (See mail.compose.attach.dir via Config Editor)

You can know such timeout length on MS Win by next;
  NET View \\ABC\XYZ (ABC : non-existent server)
  DIR \\PQR\XYZ      (PQR : non-existent server)

If similar to this case but last used resource is mountable type, "forever mount retry" may occur. This was reported for "last download directory on floppy drive". I don't know this kind of problem still remains or not.  

Above problem may occur on "Most Recently Used Directory" which is registered to Windows Registory, because Tb may try to fall back to "Most Recently Used Directory" in some situations.
This may be a reason why "no problem after clean install of OS" in your environment. 

> Thunderbird froze before, as soon as I tried to access the mail. 
> I clicked on any mail with attachements and Thunderbird froze.

What kind of attachment?
Attached file in mail? (a subpart in multipart/mixed mail)
HTTP link? (http:// link, https: link, ...)
Link to file at file server? (file://... url)

Mail in IMAP folder? Or mail in local mail folder? (POP3 account, or Local Folders)
Or do you call RSS feed or News article by "mail"?

Can you share mail data which produces your problem?

You reported this bug on 2011-11-02.
Do you still have problem stated in your bug summary and comment #0?
If yes, no problem if no "attachment" which you call?
If yes, your problem occurs on any mail which has "attachment" you call?

You say next.
> It happens just after I upgraded to the 7.0.1 version.
> I tried to (snip) downgrade to (snip) 6.0.2.

Which version of Tb did you use before upgrade to Tb 7.0.1?
Just before upgrade to Tb 7.0.1, no problem occurred?

When you tried to upgrade/downgrade to other releases of Tb, did you check with -safe-mode always?

Have you tried new Tb profile?

If you use IMAP account, create a new profile and define an IMAP account only, disable auto-Sync(Synchronization&Disk Space, disable "keep messages on this computer ..."). 
If you have POP3 account only, create new profile and define an POP3 account only, enble "Leave Messages on Server".
In any case, disable Global Search and Indexer, disable automatic mail check, disable any automatic mail purge(retention option under "Leave Messages on Server", empty trash on exit, retention policy of any mail folder, etc.)

> I had to completely reinstall Windows XP to get rid of it.

If no problem occurs when clean install of OS, it's usually OS side problem, including installed software/installed updates after clean install of OS.
Why you don't check problem of them before merely complaints on Tb who is a victim in such cases.
Because there is no generic solution of Halting Problem, improvements of Tb in such case is impossible unless "Tb's freeze occurs in what conditions" will be reported by bug opener.

What is you purpose in this bug?
Saying complaints to developers at bugzilla.mozilla.org?
I believe no. I believe you want to say "freeze of Tb is one of critical problems" and "it should be resolved".
(In reply to fletertre from comment #8)
> No I couldn't access them. Thunderbird froze before, as soon as I tried to
> access the mail. I clicked on any mail with attachements and Thunderbird
> froze. I couldn't even see the content of the mail. It was the same result
> when I tried to access Tools\Options\Attachments (as soon as I clicked on
> "Attachements").

When did you try the Tools\Options\Attachments?
Just after restart of Tb?
Or after problem of "Tb's froze as soon as you tried to access the mail" occurred?

If latter and if no problem just after restart of Tb, problem in Tools\Options\Attachments is usually a result of Tb's froze, and the freeze may be relevant to HostResolder because next wait is seen in stack trace.
>   22  Id: 5a0.300 Suspend: 1 Teb: 7ffa4000 Unfrozen
> ChildEBP RetAddr  
>(snip)
> 065ffed4 00345cb9 nspr4!_PR_MD_WAIT_CV(struct _MDCVar * cv = 0xffffffff, struct _MDLock * lock = 0x00000000, unsigned int timeout = 0)+0x8b [e:\buildbot\win32_build_release\build\mozilla\nsprpub\pr\src\md\windows\w95cv.c @ 282]
> 065ffeec 00345db2 nspr4!_PR_WaitCondVar(struct PRThread * thread = 0x10037248, struct PRCondVar * cvar = 0x065fff4c, struct PRLock * lock = 0x02c93980, unsigned int timeout = 0x2c93a2c)+0x59 [e:\buildbot\win32_build_release\build\mozilla\nsprpub\pr\src\threads\combined\prucv.c @ 205]
> 065fff04 10036bf5 nspr4!PR_WaitCondVar(struct PRCondVar * cvar = 0x10037248, unsigned int timeout = 0x65fff4c)+0x22 [e:\buildbot\win32_build_release\build\mozilla\nsprpub\pr\src\threads\combined\prucv.c @ 547]
> 065fff10 10036f4e xul!mozilla::CondVar::Wait(unsigned int interval = 0x10037248)+0xd [e:\buildbot\win32_build_release\build\objdir-tb\mozilla\dist\include\mozilla\condvar.h @ 103]
> 065fff38 10037248 xul!nsHostResolver::GetHostToLookup(class nsHostRecord ** result = 0x065fff4c)+0x72 [e:\buildbot\win32_build_release\build\mozilla\netwerk\dns\nshostresolver.cpp @ 753]
> 065fff50 0034658b xul!nsHostResolver::ThreadFunc(void * arg = 0x01b3ce00)+0xa5 [e:\buildbot\win32_build_release\build\mozilla\netwerk\dns\nshostresolver.cpp @ 873]

Does your problem occur upon any first mail click after any restart of Tb?

Some waits after following SSL related requests are seen in stack trace.
> 0596ff50 0034658b xul!nsCertVerificationThread::Run(void)+0x37 [e:\buildbot\win32_build_release\build\mozilla\security\manager\ssl\src\nscertverificationthread.cpp @ 140]
> 0586ff50 0034658b xul!nsSSLThread::Run(void)+0xaa [e:\buildbot\win32_build_release\build\mozilla\security\manager\ssl\src\nssslthread.cpp @ 985]
Tb's SSL code uses loopback interface for Task to Task communication. So, if the connection is somehow broken at OS level, it causes Tb's wait, because Tb sends request to other Tb's task via 127.0.0.1:3241/127.0.0.1:3242 or 127.0.0.1:3242/127.0.0.1:3241 connection but it won't be passed to other Tb's task by OS.
> netstat /b /n /o Output sample on MS Win XP 
> Connection via loopback #1
> TCP 127.0.0.1:3241 127.0.0.1:3242 ESTABLISHED 2308 [thunderbird.exe]
> TCP 127.0.0.1:3242 127.0.0.1:3241 ESTABLISHED 2308 [thunderbird.exe]
> Connection via loopback #2
> TCP 127.0.0.1:3243 127.0.0.1:3244 ESTABLISHED 2308 [thunderbird.exe]
> TCP 127.0.0.1:3244 127.0.0.1:3243 ESTABLISHED 2308 [thunderbird.exe]

This is a particularity of Tb, and loopback related problem in your environment may not affect on many other applications in your environment.  
Was these Tb's connection via loopback interface kept as expected when your problem occur?
(Reporter)

Comment 18

7 years ago
Hi,

"What is you purpose in this bug?"
I had no intention of complaining of Tb developpers. The work you're doing is great
I opened this bug much before reinstalling Windows, which is so time-consuming. I didn't want either to change to another mail application. I like Thunderbird, I like the spirit of it. My purpose was to find a solution to this problem and be able to read my emails.

"Tools\Options\Attachments"
It froze for more than 15 minutes. It is maximum I waited before killing Tb. It did not use 100% CPU as I could go on working on the other applications I was using. Can't say for the 2 other options.
I am a stand-alone PC, not using any network or mountable resources.
At the time I looked in prefs.js to check the last directory I used was still ok.

"What kind of attachment?"
Any kind, as soon as there was a paperclip. POP3 account.
I don't have the problem anymore. I can read mails with attachments with no problem. 
I've just check in the error console and found one "Warning: Use of getAttributeNodeNS() is deprecated. Use getAttributeNS() instead. 
Source File: chrome://messenger/content/messenger.xul
Line: 0"

"Which version of Tb did you use before upgrade to Tb 7.0.1?"
Previous version: 7.0. 
It is the main thing I did just before the problem occurred. It worked fine until I upgraded to 7.0.1.
When I upgraded/downgraded to other version I did try safe mode on some versions but not always (don't remember which ones).
 
"Have you tried new Tb profile?"
Yes. Didn't change anything. 
The options I remember were:
- Leave message on server: enabled (for at most 14 days)
- Empty trash on exit: disabled
- Check for messages...: enabled

"I had to completely reinstall Windows XP to get rid of it."
I said what I could about the specific conditions but it is not easy to find the very reason of the problem. I couldn't find alone the application which was causing the problem. What I could was to give any required information. 
But the main thing I did just before the problem occurred was to upgrade Tb! It worked fine until I upgraded to 7.0.1.
I don't know about the Halting problem but finding a generic solution for any problem and any application is different to find a specific solution to a specific problem (freeze for attachments) on a specific application (Tb).

Thanks for the time you're spending on the case.
(Reporter)

Comment 19

7 years ago
Just saw your last comments too late...

"When did you try the Tools\Options\Attachments?"
After relaunching Tb. Couldn't do it after a freeze as it was frozen.

"Does your problem occur upon any first mail click after any restart of Tb?"
Yes, on any first mail with attachment click.

"Was these Tb's connection via loopback interface kept as expected when your problem occur?"
Sorry, what do you mean? I don't understand.
(In reply to fletertre from comment #19)
> "Was these Tb's connection via loopback interface kept as expected when your
> problem occur?"
> Sorry, what do you mean? I don't understand.

I meant: shown TCP connection status for thunderbird.exe by "netstat /b /n /o", which uses IP address of 127.0.0.1.

> TCP 127.0.0.1:3241 127.0.0.1:3242 ESTABLISHED 2308 [thunderbird.exe]
> TCP 127.0.0.1:3242 127.0.0.1:3241 ESTABLISHED 2308 [thunderbird.exe]
Above roughly means; 
Task-1 of Tb opens IP address=127.0.0.1(IP address of localhost), Port=3241.
Task-2 of Tb opens IP address=127.0.0.1, Port=3242.
Task-1(127.0.0.1,Port=3241) connects to Task-2's port(127.0.0.1,Port=3242).
       Task-1 sends request to Task-2 via this connection.
       Task-2 waits request from Task-1 via this connection.
Task-2(127.0.0.1,Port=3242) connects to Task-2's port(127.0.0.1,Port=3241).
       Task-2 sends request to Task-1 via this connection.
       Task-1 waits request from Task-2 via this connection.
OS's loopback service automatically delivers request from Task-1(127.0.0.1,Port=3241) to Task-2(127.0.0.1,Port=3242), and automatically delivers request from Task-2(127.0.0.1,Port=3242) to Task-1(127.0.0.1,Port=3241).
This is one of simplest Task to Task communication which utilizes convenient loopback service of OS. No queuing mechanism by Tb himself is needed. This can be used with simple send/receive mechanism.

If you disable this loopback interface of OS, some Tb's tasks such as SSL task can't communicate each other.
Loss of this kind of connection"like next was reported to some bugs.
> TCP 127.0.0.1:3241 127.0.0.1:3242 ESTABLISHED 2308 [thunderbird.exe]
does exist, but
> TCP 127.0.0.1:3242 127.0.0.1:3241 ESTABLISHED 2308 [thunderbird.exe]
somehow doesn't exist after some errors such as network error. 
This also causes wait in SSL task, if the broken loopback connection is one for SSL task.

Can you still re-produce your problem? If yes, check with "netstat /b /n /o" command, please.
(In reply to fletertre from comment #18)
> stand-alone PC, (snip)

Does it mean "PC of no network card nor modem" or "PC with network card/modem but no LAN cable/no modular cable is connected"?
(POP3 account is dummy account with which connection timeout always occurs)
If so, timeout of DNS Lookup may be possibly very long, and loopback interface may be disabled...

Comment 22

7 years ago
Read my earlier comment again - I'm not suggesting "implement generic solution ... on any program code relevant to Tb..."  I'm saying fix it exactly where the Thunderbird code calls the specific Win32 api for this specific TB hang (on preview/read email with attachment).

(In reply to WADA from comment #16)
> (In reply to psirois from comment #15)
> > have you isolated this Thunderbird hang to a specific Win32 api call?
> 
> David merely says that resolving Halting Problem is impossible, because you
> looks to be asking developers to implement generic solution of Halting
> Problem on any program code relevant to Tb including Tb himself and Win32
> api etc.

Comment 23

5 years ago
Created attachment 734301 [details]
Thunderbird crash on email w/ attachment

Still repro's in Thunderbird 17.0.5 on Win XP sp3, stack trace attached.

Comment 24

4 years ago
24.5.0 hangs if I open an attachment via OLE, it does not if I save it. WinXP SP3. There is no crash report as it hangs, not crashes.

The problem lasts for a couple years now.
You need to log in before you can comment on or make changes to this bug.