[go: nahoru, domu]

Open Bug 1092593 Opened 10 years ago Updated 2 years ago

Thunderbird hangs forever after Network Outage of local Folder Storage on SMB network share

Categories

(MailNews Core :: Networking, defect)

x86_64
Linux
defect
Not set
critical

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: u522202, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: hang)

User Agent: Mozilla/5.0 (iPad; CPU OS 8_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12B410 Safari/600.1.4

Steps to reproduce:

Local folders are stored on a SMB network share. Try to access these local folders.


Actual results:

After a network outage the connection stucks and there is no response from Thunderbird. Thunderbird must be killed and the SMB share must be dismounted and mounted again to recover.


Expected results:

The local folders must be accessible after a network outage.
OS: Mac OS X → Linux
Hardware: ARM → x86_64
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Why it should be duplicate of 1092591?

The network protocol is different (SMB vs. IMAPS) and the component is also different (IMAP postbox vs. local folder). Also the recovery method is different (Restart of Thunderbird vs. killing of Thunderbird and remount of SMB share).
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
As a result of the hang the user see no screen update of Thuderbird and no response of Thunderbird.
It sounds dup of bug 482665.
(In reply to WADA from comment #4)
> It sounds dup of bug 482665.

With bug 482665 it's not clear if Thunderbird must be killed to recover.  And if the SMB mount has to be remounted or not. Because, with this bug you have to remount the share, otherwise, immediately after killing and restarting Thunderbird it hangs again and must be killed.
(In reply to info from comment #5)
> (In reply to WADA from comment #4)
> > It sounds dup of bug 482665.
> 
> With bug 482665 it's not clear if Thunderbird must be killed to recover. 
> And if the SMB mount has to be remounted or not. Because, with this bug you
> have to remount the share, otherwise, immediately after killing and
> restarting Thunderbird it hangs again and must be killed.

And with this bug, the profile is stored locally, only the storage is remote!
Severity: normal → critical
Component: Untriaged → Mail Window Front End
(In reply to info from comment #6)
> (In reply to info from comment #5)
> > (In reply to WADA from comment #4)
> > > It sounds dup of bug 482665.
> > 
> > With bug 482665 it's not clear if Thunderbird must be killed to recover. 
> > And if the SMB mount has to be remounted or not. Because, with this bug you
> > have to remount the share, otherwise, immediately after killing and
> > restarting Thunderbird it hangs again and must be killed.
> 
> And with this bug, the profile is stored locally, only the storage is remote!

Good info, but does not necessarily make this report unique or the distinction relevant. 

FWIW, in the last couple days I worked with a Mac user who had a usb external drive attached to Mac using Thundebird in Windows under Parallels.  Somehow the connection with the external was lost, and Thunderbird did not hang, and there were no errors IIRC, but the message list pane would act goofy when clicking a local folder and mousing over the message list.
Component: Mail Window Front End → Networking
Keywords: hang
Product: Thunderbird → MailNews Core
Summary: Thunderbird hangs forever after Network Outage of local Folder Storage → Thunderbird hangs forever after Network Outage of local Folder Storage on SMB network share
See Also: → 1092591
Yes, possibly we have to categorize this kind of bugs in another direction.  Possibly these bugs are very much connected to the communication layer of the operating system used and how the various error conditions are handled within Thunderbird.  The question is how Thunderbird uses the system libraries and handles the multitude of return values.

And if we put them all together within one bug, we must use a matrix of test cases to not miss any cause of error:
- Windows, Linux, Mac OS-X
- whole profile stored on a share, only local folders stored on a share
- connection errors in: SMB share, USB drive, NFS share, WebDAV share, ...
- connection errors to: IMAP postbox, POP postbox, ...
 just filed

Bug 1164283 - C-C TB crashed in ftell timing out due to transient network error (user profile on remote file system)  

and found this bugzilla while checking bugzilla entries suggested as similar when I tried to enter my own entry.

(In reply to info from comment #8)
> Yes, possibly we have to categorize this kind of bugs in another direction. 
> Possibly these bugs are very much connected to the communication layer of
> the operating system used and how the various error conditions are handled
> within Thunderbird.  The question is how Thunderbird uses the system
> libraries and handles the multitude of return values.

Over the course of the last few years, I found that TB fails to handle
return values properly. Most of the errors I have encountered myself can be traced to such ignorance of error return values :-(

> 
> And if we put them all together within one bug, we must use a matrix of test
> cases to not miss any cause of error:
> - Windows, Linux, Mac OS-X
> - whole profile stored on a share, only local folders stored on a share
> - connection errors in: SMB share, USB drive, NFS share, WebDAV share, ...
> - connection errors to: IMAP postbox, POP postbox, ...

Interesting idea.
I am chipping away some bugs from C-C TB by testing mostly on linux using
profile + local storage on remote file system (CIFS against Win7, a router box with USB memory stick support:FAT32 will be visible as network share, AND NFS on another linux PC). 
My testing was concerned mostly with POP3, but I have started to mix IMAP testing by creating an additional test account.

But even with the testing of this limited scope,
it seems that I am hitting core bugs that affect majority of upper layer combinations. 

Still, if we can find one user willing to test in one combination each of the above, we will be better off :-)

To honest, if we can find a maker of CIFS file server devices that may return short write/read under moderate load and if the maker is willing to offer a remote access to such a device, I think we can shake out many I/O bugs easily. Any ideas?

I
Depends on: 482665
See Also: → 1164283
See Also: → 1803913
You need to log in before you can comment on or make changes to this bug.