287658 - Saving to local folders (Sent, Drafts) spins forever !

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Michael Greenspon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

This same bug has existed in every version of Mozilla I can recall back to 1.3
on Win2K; other have reported it back to 1.2, now on 1.7.5 on XP. Here are some
other bug# cross refs-- 
https://bugzilla.mozilla.org/show_bug.cgi?id=237393#c8
https://bugzilla.mozilla.org/show_bug.cgi?id=185955#c1

Although retrieving mail from an IMAP server, this bug is being unable to save
to LOCAL folders, e.g. sent and drafts. It happens after Mozilla has been
running for "a while" and the only fix is to quit and restart which is a SHOW
STOPPER for anyone who uses the program seriously day in and day out.

To reproduce it,

1. Run mozilla for "a while" (as a power user-- retrieve a few hundred mostly
spam emails from IMAP, filter for junk and message filters, maybe send some
emails, open a few dozen tabbed pages, etc.)

2. After "a while", notice that any attempt to save a new message as a draft in
local Drafts spins forever, until cancelled. Upon cancelling, the draft has not
been saved. Side: in 1.4 there was a variation where the draft was saved, but
drafts folder view would not update (even if closed and reopened) until a
message was deleted from the folder, at which point the saved draft which spun
would show as having been saved. This is NOT that bug, instead we are now not
able to save the draft at all, the folder write never happens.

Same for "sent" message copied to local sent folder. Outgoing emails are sent
fine, this is not a problem with SMTP, IMAP or anything to do with the network.
After the message is sent, the attempt to save the copy in the local sent folder
spins forever until cancelled at which point the copy has not been saved.

If I had to guess I'd say this is a problem with folder locking or sharing;
mozilla is spinning waiting for a write go ahead to the local folder that it
never gets, perhaps some other thread of itself has the folder blocked. (Perhaps
a side effect of cancelling various long running IMAP operations,
retrieving/filtering hundreds of spams, server disconnects-reconnects etc.) 

This SERIOUSLY needs to get addressed NOW, it is a showstopper that requires a
restart of mozilla to clear which is obviously unacceptable! This is one of a
small handfull of killer bugs that have reared their ugly heads on a daily basis
in every version of mozilla for YEARS. Thanks.


Reproducible: Always

Steps to Reproduce:
1. see description
2. run mozilla for a while, do lots of stuff that a power user with IMAP does
3. notice that you can no longer save messages, drafts or sent copies, to local
folders

Actual Results:  
See details above

Expected Results:  
Mozilla should be able to go for MILES with hundreds of tabs opened and
thousands of messages processed for MONTHS at a time without narely a hang,
crash or restart required. Please drive for THAT level of solidity so that the
browser can become invisible to the workflow.

Comment 1

[timeless]

well, you could try
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html but as is, this
report isn't remotely helpful. (and yes, i do use mail, and yes i use imap for
long periods of time, although i rarely use drafts and i don't use filters, i do
let bayesian run, but do not allow it to delete/move items, only mark).

Comment 2

[Serge Gautherie (:sgautherie)]

Could you try with a Trunk (v1.8b1 +) build too ?

Comment 3

[Mike Cowperthwaite]

Dupe of bug 206408?

As would be, I think, bug 185955 and bug 263035.  I'm pretty sure there are 
others; these cropped up on a very restrictive set of search criteria.

This *has* been a long standing and much reported bug; however, demanding a fix 
is more likely to *reduce* the chances of it getting fixed.  (It is also quite 
unlikely fixed in the "most recent trunk build," but I imagine reporter doesn't 
need to be convinced of that.)


See bug 206408 comment 48 et seq, and bug 263035 comment 3 et seq, for 
information on the state of debugging this problem.

Comment 4

[Michael Greenspon]

(In reply to comment #3)
> Dupe of bug 206408?

Thanks for the cross refs. I did find some of these in my initial search,
however they seemed to diverge into irrelevance, part of the problem being that
you have a bunch of naive users reporting all these different situations,
including saving copies to IMAP folders which is not what this is about. I had
not found bug 206408 in my search. Perhaps someone could merge these reports
into that thread.

https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c21
Here this starts out relevant but then by
https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c28
Bienvenue gets off track on a case of copying folders, which is not necessarily
what this is about. This is about saving a message to a local folder. I have a
factory vanilla local folder set, I do not create, move or trash local folders.
All IMAP mail is kept on server and filtered to server folders, Junk is on the
server. Only drafts and sent copies are saved locally. I have only one user
account/profile, but that profile has been migrated through multiple versions
(starting with 1.4a probably.)  

It seems to me that when one local folder write spins also all other subsequent
write to that local folder (but not necessarily other local folders) also spin,
and the only fix is restart mozilla. I've never seen this get unstuck during a
session.

My current mozilla session is in this stuck state so I'm trying to exercise it.
I am seeing that if I save a draft, it spins, I cancel. I then delete a
preexisting draft from the folder, now a minute or more later the message that
the save spun on appears in the drafts window! I now get a chain of 'unable to
save message in sent folder' dialogs, probably from a dozen previously sent
emails that spun on the save to sent folder. I cancel all of these. Now if I
save new drafts, it still spins, but if I cancel and then delete a message from
the drafts folder, the saved-spun-cancelled messages appear immediately. So in
addition to the save spinning, the view is not being updated (even if the window
is closed and reopened) until a message is deleted from the folder. Notably the
delete does not block.

The 'workaround' https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c42 does
not seem to work. It still spins on save.

Also I have about 1900 drafts, since I use this folder to keep notes not just
for message composition. Sent has about 5700 messages (dating back to 1997.) My
IMAP is on an internet remote server with a comparatively slow connection and on
a slow machine (Ultra 1--vintage 1996) with not enough RAM and large mail folders.

https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c48 is relevant, maybe I'll
run mail separately, so I can kill it without zapping a week's worth of open
browers. (Great product endorsement.) [BTW now that there are tabs, someone who
wants to advance this tool please implement 'one button restore' of all open
browser tabs/windows across sessions. Save the global state.]

https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c51 seems absolutely bogus,
this is unlikely a problem with any particular IMAP server and probably not IMAP
related at all (unless an uncompleted op is causing the local folder state to
remain locked in some way.) I'm running Crispy's (UW) IMAP not cyrus.

https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c67 is exactly relevant.
Couldn't have said it better myself. Wow, this must be deja vu!

Instead of telling me to try the latest trunk build, someone please build me a
version that has a bunch of debugging/diagnostics and error reporting in this
save to local folder section and I'll run THAT.

Further exercising... moving message from 'Drafts' to local Inbox (empty) works
immediately and shows 1 message in local Inbox. Trying to move the message back
from local inbox to Drafts does nothing, no spin, no move. So the spin/blocked
situation is on a per folder basis, e.g., Drafts and Sent, the actively written
local folders, are in this stuck state.

https://bugzilla.mozilla.org/show_bug.cgi?id=263035#c11 seems completely
relevant. So fix it! Maybe a major overhaul is called for. I am constantly
juggling windows and sending multiple messages, often running multiple ops
before others have completed, and I expect the tool to keep up. Get your
internal serialization model fixed so that all these user logical threads of
action do not result in multiple os threads deadlocking with each other.


> As would be, I think, bug 185955 and bug 263035.  I'm pretty sure there are 
> others; these cropped up on a very restrictive set of search criteria.
> 
> This *has* been a long standing and much reported bug; however, demanding a fix 
> is more likely to *reduce* the chances of it getting fixed.  (It is also quite 
> unlikely fixed in the "most recent trunk build," but I imagine reporter doesn't 
> need to be convinced of that.)
> 
> 
> See bug 206408 comment 48 et seq, and bug 263035 comment 3 et seq, for 
> information on the state of debugging this problem.

Comment 5

[David :Bienvenu]

The problem with fixing this is that I've never found a reliable set of steps to
reproduce the problem. Banging  on it like a monkey on meth is helpful
information but not sufficient :-)

I have found a set of steps to recreate this, however:

1. Bring up two compose windows with large attachments.
2. Copy a large number of messages from one local folder to another.
3. While that copy is going on, save both drafts.
4. While the save is spinning, waiting for the msg copy to finish, cancel one of
them.
5. When prompted if you want to retry, say OK.
6. At this point, the drafts folder will be locked and subsequent attempts to
save drafts to it will fail.

The reason it's failing is that one of the copy requests for a copy to the
drafts folder never got cleared from the nsMsgCopyService list of copy requests,
m_copyRequests, so we think we're still busy copying to that folder. I believe
the request is getting cleared from the nsMsgDBFolder (which is another
potential problem), but not from the copy service, so our cleaning up from some
error case is not correct.

I'll try to figure out what's causing the request to get stuck in the copy
service...

Comment 6

[Michael Greenspon]

David, thanks for your note. Sounds like you found a way to leak a lock with
multiple long running local ops without the network. This may or may not be the
particular lock leak that we're seeing, but I'd gamble it's a wide-spread
problem in Mozilla, so this would be as good a time as any to track 'em all down
(or revamp the methodds) since being able to reliably perform multiple long
running ops concurrently is one of the strong functional points of Mozilla. 

For example your note seems to imply a chunky rather than fine grained locking
granularity, e.g. per copy op (one or more messages copied per op) rather than
per message copied. Not that this is necessarily bad or wrong but just a bit
different than the way I would have guessed you are making copies. 

There are other places where serializing ops like this is not in the user's best
interest, for example every morning while Mozilla is filtering the hundreds of
daily spams, there are several periods of time when it is unresponsive to the
user selecting individual messages for viewing-- it is still processing the
filtering (or has queued a bunch of retrieval requests to the server, or
something) and all these mesages must complete processing before the user's
request for retrieving a single message is processed. This is usually the time I
go get a coffee, etc. but it would obviously be desirable from a functional
standpoint to prioritize the foreground requests (and I understand in this
example it may be a long roundtrip pipeline packed with messages.)

I'd urge you to refer again to comments at
https://bugzilla.mozilla.org/show_bug.cgi?id=263035#c11

good luck and I'd be happy to try any particular tests you think might be
relevant or to try running an instrumented build etc. (as long as it won't
corrupt my message databases) to log where locks are obtained, released and
where request ops or threads are queued and where they exit without having
released the locks.

Comment 7

[David :Bienvenu]

Attachment: make cancel abort the msg copy operation

This patch makes cancelling the progress dialog abort the message copy
operation, which should unlock the target folder. For my test case, it fixes
the ultimate problem of the drafts folder getting locked out.

However, there is still an underlying problem. In my test case, the copy fails
when the initial mass msg copy finishes, even if I don't cancel the save
operation(s). It shouldn't fail - it should just perform the first save as
draft and then when that finishes, it should do the second one. I'll look at
that next.

Comment 8

[David :Bienvenu]

Attachment: fix to make save as happen immediately

This fixes the second problem I described before:
in my test case, the save as draft to a local folder should complete
synchronously, and not care that a message copy is going on. The reason it
wasn't was that copySource was not cleared when going through this loop, so the
save as draft was inheriting the copy source from the message copy, from the
previous time through the loop, which caused us not to send an endcopy, and all
sorts of bad things happened. Clearing copySource each time through the loop
fixes that.

Comment 9

[David :Bienvenu]

fixed on trunk; please try tomorrow's trunk thunderbird or seamonkey build.

Comment 10

[David :Bienvenu]

Comment on attachment 178822 [details] [diff] [review]
make cancel abort the msg copy operation

this is an oft-duped bug.

Comment 11

[David :Bienvenu]

Comment on attachment 178861 [details] [diff] [review]
fix to make save as happen immediately

this is a simple fix for potentially a lot of msg copying problems.

Comment 12

[David :Bienvenu]

*** Bug 288964 has been marked as a duplicate of this bug. ***

Comment 13

[David :Bienvenu]

*** Bug 123063 has been marked as a duplicate of this bug. ***

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 178822 [details] [diff] [review]
make cancel abort the msg copy operation

1.7.7 has shipped. unsetting request.

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 178861 [details] [diff] [review]
fix to make save as happen immediately

1.7.7 has shipped. unsetting request.

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 178822 [details] [diff] [review]
make cancel abort the msg copy operation

1.7.7 has shipped. unsetting request.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 178861 [details] [diff] [review]
fix to make save as happen immediately

1.7.7 has shipped. unsetting request.

Comment 18

[Graham Leggett]

*** Bug 263035 has been marked as a duplicate of this bug. ***

Comment 19

[Graham Leggett]

*** Bug 185955 has been marked as a duplicate of this bug. ***