I apologize in advance, this initial description has to be very vague since I have no clue as to why I see the behavior I do. I hope to get some input on what I shall do to help debugging. I see this behavior with the current trunk version (compiled myself) and it started about 7-10 days ago. I'm using a local imap daemon and most of the mail is in local mail folders, automatically sorted by a number of filters. I've tried everything with and without junk mail filtering. This is a more or less stock Red Hat 8 system. The symptom: after a while, sometimes only a few seconds, sometimes an hours or so, the mailer gets into a state where it does not let me delete any messages. Once this happens I cannot even select another message for viewing anymore. Actually, I can, but it must be in another storage. I.e., when I cannot delete a message in the imap account I still can view messages in local folders. But I cannot delete messages in local folders either. If the problem first appears when working on local folders moz occasionally display a warning that an operation is still in progress. This message persists even if I exit moz and restart it. When I use instead of the trunk version the stock mozilla-1.0.1-26 which comes with an updated Red Hat 8 installation I see no problem at al (just as I haven't seen this problem before). One more thing: I /think/ that it all started after receiving a (legitimate, not junk) mail with binary data included. Somebody just added a binary to the message without any protected (attachment, uuencode, etc). This message was automatically moved, by one of the filter rules, in a local folder. I dodn't run compact folders anytime soon so I expect it still was present in the imap folder as well. When this message arrived I couldn't do anything anymore (similar to what I see now regularly). Restarting mozilla or imapd or sendmail didn't have any effects. I hand-edited the /var/spool/mail/* file to get rid of the offending message in the imap server. After that I could work mostly normal for brief periods of time. Possible question: could one or more of the mail databases mozilla keeps be corrupted? Why does mozilla-1.0.1 work flawlessly? Please suggest further questions and experiments. I'll try to download an use a nightly build of the trunk version but I doubt that this is a problem. I'm building my own mozilla for many many moons and never had any problems caused by that.

Some more info: I downloaded the nightly built (the binary available at 10:43a PST on 2002-11-30) and it shows the same behavior. I started this version, deleted two mails I couldn't delete beause of this problem in the last session and then let the mail part just sit (i.e., I didn't look at mail). When I looked at it again after about 30mins I couldn't remove any of the newly arrived mails. And one more on viewing messages: I cannot view any other message in the folder once deleting fails. If I the problem happens in the imap folders and I go and look at local folders this works (watching, not deleting). If I then go back to the imap folder I can once again look at all messages. Even the one which I tried to remove. This switching between messages works fine until I try to remove something. Then once again I cannot look at any other message (until I look at local folders first).

And one more: Apparently polling the imap server also stops once deleting in the imap folder fails. When I restart moz new messages are immediately displayed so I assume this is no problem with the imap server.

And yet more: I forgot to mention that I normally install the CVS moz version every day. I.e., the bug persisted the whole time since it first appeared. I'm now using 1.2.1 and in 24+ hours of use I haven't seen any sign of this problem. Note, these are the same files. From this I gather something is really broken in the CVS trunk mailer.

I think that this is the bug that endico and I are seeing on linux. If this is widespread we really shouldn't release 1.3a without a fix.

drepper, can you start a imap protocol log, so that we can look at it the next time this happens to you? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

> drepper, can you start a imap protocol log, so that we can look at it the next > time this happens to you? Sure. Will do it a bit later tonight. It's very easy to reproduce.

This is the log I got by setting NSPR_LOG_{MODULES,FILE}. Both, deleting in local folders and deleting in imap failed in the end. I'm not sure, though, whether this is reflected in the log. I ran tail -f on the file and didn't see progress in that moment. Maybe some caching? Please note the log file is obsfucated. I cannot leak company mail, machine names, addresses and so on. If this is a problem you'll have to contact me so that you can get a file without me posting it on public.

Just to provide another data point: I'm seeing this as well on all Linux CVS builds I did for the last two weeks or so. However, I'm not using imap. I have all my mail in local folders, via movemail. (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021010) I can reliably reproduce the problem: o Freshly start Mozilla, and open MailNews (o Delete a couple of *single* messages - this works flawlessly) o Now, highlight *more than one* message and try to delete them, either via the context menu or the delete button - this reliably fails for me: the messages are not deleted o after this, several things stop working: - I can no longer delete any messages, either singly or in batches - dragging mails to the trash folder doesn't work anymore - mail is no longer displayed in the message pane after clicking on it - however, double-clicking the message displays it correctly in a new window - ... but I can't delete it there either Closing and reopening the MailNews windows doesn't help, but if I then close Mozilla and restart, everything is back to 'normal', until I again try to delete more than one message at a time. Two things I tried, without success: o I deleted all .msf files, and had Mozilla recreate them - still happens o It's not restricted to the Inbox, but rather happens in any folder So far I didn't find any duplicates of this in Bugzilla - this should be rather high-profile, since batch-deleting mail is such a common task. I thik I'll post a message to the mailnews forum, and see if other people are seeing this. If this is a general problem, this should indeed block 1.3a ...

taking. I'll try multiple deletes.

this worked for me in my quick test - delete a few local messages singly; then select 2 or 3 messages and press delete. Perhaps a silly question - do you have a trash folder?

> Perhaps a silly question - do you have a trash folder? Yes, there are trash folders for imap and the local folders.

I saw this yesterday on my Linux box, and remembered to check the JavaScript console, and I didn't see any exceptions or other JS errors. Could it be a timer issue? FWIW, I can't reproduce _at will_ either, with comment 8, but I'll keep trying.

Re: #10: yes, the trash folder is there, and it's doing its job quite well in the case of deleting single messages - but once I try deleting more than one message at a time, this and all subsequent deletes fail, no matter whether they are batch or single. I found out another thing while trying to post a request for confirmation of this bug to the mailnews group: once I'm in the hosed state, I can no longer send messages (either mail or news) as well! The progress indicator hangs at 'Copying message to Sent folder', barber pole spinning and all, but never finishes. I then switched of saving sent mail in the Sent folder, and the message went out fine. Once I reenabled the Sent folder, I could again not send mail or post news. It seems that writing to folders is what is causing operations to fail.

Christian, that's an interesting data point. Can you move/copy messages to any other folders once you're in this state? There's a per-folder state that tells us if we're copying messages into it, and we won't allow another copy into that folder if that state is set. But there isn't a global setting that disables move/copy. Ulrich, what the imap log shows is you deleting three messages, one by one, then compacting your inbox. Nothing seems to be happening after that. (only imap stuff shows up in the log). Now, having a local imap server historically has been the cause of some problems, but mostly cpu contention issues - you're not seeing the cpu pegged once you get into this state, are you? Is one of these three messages the one you saw about an operation in progress? filterFolderDeniedLocked=The messages could not be filtered to folder '%S' because another operation is in progress. parsingFolderFailed=Unable to open the folder %S because it is in use by some other operation.Please wait for that operation to finish and then select the folder again. deletingMsgsFailed=Unable to delete messages in folder %S because it is in use by some other operation. Please wait for that operation to finish and then try again. I can't imagine this persisting across mozilla sessions, unless you're using quicklaunch (but I didn't think we did quicklaunch on linux)

using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021203 on linux 2.2 I can't reproduce this on imap or pop account. It seems to work for me. But Local folders is busted? I cannot do a multiple move or copy of mesgs to a folder under Local Folders. I can do multiple move/copy from one imap to another imap. So moving/copying multiple mesgs is broken than maybe deleting mutliple mesgs is to? Soundss like the old cyrus mail server bug. Mabye fix for that broke this?

> Can you move/copy messages to any > other folders once you're in this state? There's a per-folder state that tells > us if we're copying messages into it, and we won't allow another copy into that > folder if that state is set. But there isn't a global setting that disables > move/copy. As mentioned in the message I posted with the log, I have problems deleting in any other folder once this starts. Even if the problem turns up while working on imap. There is a trash folder on the imap server so no state of the local folders should (in theory) effect the imap operations. > Ulrich, what the imap log shows is you deleting three messages, one by one, > then compacting your inbox. Nothing seems to be happening after that. Correct, since I switched to using local folders. > Now, having a local imap server historically has > been the cause of some problems, but mostly cpu contention issues I don't think this is a problem. I would hear the CPU fans running quicker if the CPU load gets higher. > Is one of these three messages the one you saw about an operation in progress? The message moz prints about an operation in progress does not mention any specific message. It just says that some operation is in progress. > I can't imagine this persisting across mozilla sessions, unless you're using > quicklaunch (but I didn't think we did quicklaunch on linux) It's not persistant over the end of a session, definitely not.

note on comment 13 I see the same thing when trying to send a mesg from a pop account. I have pref 'place copy of mesg to sent folder on foo@foobar.com' (my sent folder under my mail account) and it hangs when I hit send. I see 'copying mesg to sent folder' and status bar scrolling also. When i switch the pref to 'sent folder under Local folders', I can send mesg but then I get a mesg 'could not be copied to sent folder would you like to return to compose window'.

> When i switch the pref to 'sent folder under Local folders', I can > send mesg but then I get a mesg 'could not be copied to sent folder > would you like to return to compose window'. I see this as well (my Sent folder is local) but only once the delete problem appeared. I wouldn't have problems if I never had to delete mail.

Re: #14: > Christian, that's an interesting data point. Can you move/copy messages to any > other folders once you're in this state? There's a per-folder state that tells > us if we're copying messages into it, and we won't allow another copy into that > folder if that state is set. But there isn't a global setting that disables > move/copy. Ah, that was a very useful poke in the right direction! (in the following, if I say 'moving', I'm talking of dragging messages between arbitrary folders on the local machine) o first, I tried moving a single message while in the 'working' state -> works o then I tried moving multiple messages between the same two folders -> fails! o after this failure, moving a single message also fails! -> the receiving folder seems to somehow 'block' o ... however, moving messages to *any other* than the 'blocked' folder works o ... as does deleting messages OK, so far, it seems like any folder (including Trash) that is supposed to receive a batch of messages instead of just one, somehow wedges. *But*: this does not explain the blocking due to the 'Sent' folder! Either by deleting multiple messages, or by moving multiple messages between folders, I always end up with 'writing to Sent' not returning - BTW, the message is still sent (see my double posting in n.p.m.m), but the composition window doesn't close while endlessly trying to write to 'Sent'

I actually see this every couple of days on Windows. It's always during single delete. Generally I'm deleting very quickly - hitting the delete key repeatedly. Eventually delete will stop working. I don't remember if message display is broken, but delete is and I have to restart. This is IMAP with Move to Trash set.

Know what? I see the problem now also in 1.2.1. In an imap folder. I got some mails with Japanese characters. I'm using Xft and apparently no font matches, so they are all displayed in the Unicode number boxes. This is not the first Japanese message, though, I don't know what makes it special. It started after I deleted multiple blocks on mail in fast succession. What I see is that I cannot remove said message. Once I try I does not work and any other work in this folder is stopped, for a while. After a little while I can look at other messages in the folder again (even without temporarily switching to another folder). So, the symptoms are a bit different and only temporary. But it doesn't matter how often I try, I cannot remove these two messages. All the other messages in the same thread (some at last used Japanese encodings) are gone meanwhile. The two messages in question are encoded in UTF-8. What I think all this shows is a) that it has something to do with timers b) and that non-ASCII (non-displayable?) signs play a role

Marking as a 1.3a blocker.

that's possible - I know that Asa had problems after selecting a message that generated some strange css errors about 'mso-ascii-font-family'. I don't know why that would cause problems in IMAP. Perhaps you could forward me the message and I could try it on Windows...

This is one of the mail I have problems with in 1.2.1.

And another data point. I've cleaned up my imap folder, leaving only the mail I posted in it. Delete didn't work. Another mail arrived and suddenly I was able to delete the problematic mail (and the new one). The imap daemon apparently accesses the mail file correctly since I can watch them correctly. Also, 1.0.1 and usually 1.2.1 have no problems accessing the messages. Does the mail backend somewhere, somehow do charset conversions?

OK, one thing that I know is going on is that urls are getting queued (i.e., waiting for other urls on the same folder to finish) and then not getting run. Whenver we finish running a url, we run the next available url in the queue. What's happening is that urls are getting put in the queue but not run until another url is run - biff/check for new mail will cause the queue to get flushed because it's another url run. Sometimes when you get in this situation, clicking get new mail will cause the queue to get run. I'm still trying to come up with a fix for the urls getting queued but not run problem.

the imap code doesn't do charset conversions, but I think the mime code does. I'm going to attach a patch that anyone with a debug build is encouraged to try - it might help with the stalling problem. I'm very interested in having the people who've been seeing these problems try the patch. I can't promise much, but I believe it will help, as much as I can without being able to reproduce the problem.

this fix tries to run any queued urls after adding a url to the queue - most of the time, it will fail harmlessly, but in the race condition case, it might prevent the stall.

Is the patch perhaps reversed? As it is it does not apply since more or less exactly this code is already included.

yeah, that's because I suck and attached the wrong patch. Let me try again.

this is the patch that I meant to attach before.

other old delete bugs : bug 57950 and bug 63550.

I tried the patch and unsurprisingly, it didn't help. I had the problem this time with local folders and the patch only modified imap files. I've cleaned up my imap folders to be small enough to probably not have the problem anymore.

the bug will happen any time a delete fails to complete for whatever reason, if it doesn't actually generate an error condition. This conceivably can happen for both imap and local folders, for different reasons. This patch was only attempting to address a potential issue for imap folders. If getting new mail fixes the problem, you're definitely having the url queue get stalled (that's why it looks like a timer problem to you - the timer is the biff timer). I'm not sure what having a smaller imap folder has to do with this. Are you saying that this tends to happen more with larger folders? Also, I guess I don't understand this comment: "And another data point. I've cleaned up my imap folder, leaving only the mail I posted in it." What does this mean, exactly? Do you mean only messages from you, somehow? What does "posting" mean in the IMAP context?

> I'm not sure what having a smaller imap folder has to do with this. > Are you saying that this tends to happen more with larger folders? You need to be able to delete a few messages in a row. This is why I couldn't test it today. Most of my mail gets presorted in local folders. I can much more easily test on local folders, so if you can have a patch for that part I'll be able to check it quickly. > What does this mean, exactly? Do you mean only messages from you, somehow? > What does "posting" mean in the IMAP context? This was referring to the mail a attached to this bug (attachment #2 [details] [diff] [review]).

Oh, I get it - you mean the problem message in that folder - I tried that message, and as you suspected, nothing bad or odd happened with it. It wasn't clear to me that you could reproduce the same problem with local folders (i.e., folders not accessed with imap, but plain old local folders stored in the berkeley mailbox format and stored either in "local mail" account, or pop3 account). I rather thought you were accessing those folders with imap as well, even though it's a local imapd, because that's a common thing to do ,especially for people who use spamassasin - I was making way too many assumptions :-( . So you're talking about mozilla mail filters filtering imap messages into true "local folders" and eventually being unable to delete messages in those local folders. I wonder if that is triggered by having imap messages filtered into the local folders while you're simulataneously trying to delete messages from the local folder.

> So you're talking about mozilla mail filters filtering imap > messages into true "local folders" and eventually being unable to delete > messages in those local folders. Yes, the same problem happens with these truely local, accessed as files, folders and with imap folders. I used the nomenclature mozilla displayed, I thought this is clear. > I wonder if that is triggered by having imap > messages filtered into the local folders while you're simulataneously trying > to delete messages from the local folder. It might be but wouldn't this be a completely different kind of problem than the one which makes deleting in imap folders hang? It would be a strange coincident if there would be two bugs, one in the imap folder handling and one in the local folder handling, which result in exactly the same erronous behavior.

It's not a completely different kind of problem. The core problem, as I said before, is that if a delete fails to notify the view code that it has finished (imap, local, whatever), then the view code will not allow any more deletes because it thinks a delete is still in progress. So, for example, if an imap delete doesn't run because the url queue gets stalled, then you will not be able to delete until the queue gets de-stalled, at which point the delete will run, and will notify the view, and the view will allow subsequent deletes to run. Another possible example is that a local delete might get interrupted or otherwise fail to complete and not notify the view code that the delete has failed. Again, in this situation, the view will think the delete is still going on, and not allow subsequent deletes. This example is somewhat hypothetical - I've tried various things with local deletes and they all send the correct notification to the view. Now, obviously, this is a bad thing that the view code is doing - I argued against it being done this way, but the bug that was fixed by this hack in the view code was a data corruption bug, so I allowed it in with the understanding that it would be fixed the right way soon. That obviously hasn't happened yet and I'm worried about re-introducing the data corruption bug. What I need to be able to do is reproduce these problems and come up with fixes so the proper notifications are sent.

I have the same problem with a POP mail account. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021206 Sometimes can't delete any more messages. Need to restart mozilla. Remember a previous version last week with systematic problem : after deleting some messages can't delete anymore (around the 20/26 november). Sometimes can't display any message in the folder. Need to select another folder then reselect the folder then messages display. Is it related ?

OK, I've found the cause for the problems doing operations with multiple messages and local mail folders (it won't have any affect on the purely imap problems). I tried running this under purify to see if there were any uninitialized variable references - purify didn't tell me about any, but it managed to change what was on the stack enough that so that the value of an unitialized variable on the stack changed enough to cause the problem. Fix upcoming.

this should fix the case of deleting/moving multiple local messages, and moving multiple imap messages to a local folder.

the main problem was caused by the use of an uninitialized rv. The problem was exacerbated by the fact that nsMsgLocalMailFolder::CopyMessages was not sending the appropriate notification when CopyMessagesTo failed, so the view code did not know the delete had failed.

Comment on attachment 108695 [details] [diff] [review] proposed fix r=dmose

Comment on attachment 108695 [details] [diff] [review] proposed fix > + NS_ASSERTION(PR_FALSE, "copy message failed"); Use NS_ERROR("copy message failed") instead.

Comment on attachment 108695 [details] [diff] [review] proposed fix ok, I've made the NS_ERROR change locally.

I've tried the patch and it doesn't change anything. As soon as I tried to delete a couple of messages from a local folder it happened again. I managed to delete perhaps 10 messages, 5 of them in one thread at a time. The problem happend when I tried deleting a larger thread all at once. I have the folder sorted by threads , opened the thread, and by pressing at the thread symbol in the left column I selected all messages. Again, this worked for the first bunch but then all failed again.

I'm sure this is going to fix the problem for some people so it should definitely be checked in. This regressed 11/27 and bug 183766 was filed 11/30 - I was able to recreate this problem under purify and this fix fixed it, so I'm sure it accounts for some of the instances of this problem (unfortunately, it seems there's not just one cause of this problem, as I indicated earlier)

... it certainly fixed my problem :-) ! With the patch applied, batch-deleting mails now works flawlessly for me, as does batch-moving between folders. Since I don't use imap, I cannot verify the imap side of the problem. Thanks, bienvenu!

Ulrich, are you running a debug build so that you can attach a console log output? That could be very informative.

Comment on attachment 108695 [details] [diff] [review] proposed fix a=asa for checkin to 1.3a. We're running out of time so please try to land this quickly. thanks.

http://bugzilla.mozilla.org/attachment.cgi?id=108695&action=view checked in (this affects moving imap messages to local folders, and deleting/moving messages between local folders). Asa and Dawn, please let me know if it fixes your problem. I think for imap only problems, http://bugzilla.mozilla.org/attachment.cgi?id=108557&action=view could still be useful - have you run with that?

> Ulrich, are you running a debug build so that you can attach a console log > output? That could be very informative. I normally don't enable debugging. If you tell me what to do (beside disable optimized builds) I can easily do it.

I think you just need to remove ac_add_options --disable-debug from your .mozconfig if you've set that and rerun configure. Or you could re-run the unix build configurator w/o selecting disable debug. I don't really know the details on linux, though everything's supposed to be the same now. On Windows, I just set MOZ_DEBUG before build to get a debug build. In theory, the optimization/non-optimization should be orthogonal because sometimes you have to debug optimized builds, but I don't know if the linux build system allows that.

Comment on attachment 108557 [details] [diff] [review] potential fix sr=sspitzer

Comment on attachment 108557 [details] [diff] [review] potential fix R=ducarroz

Comment on attachment 108557 [details] [diff] [review] potential fix a=asa for checkin to 1.3a

Comment on attachment 108557 [details] [diff] [review] potential fix checked in.

So far haven't been able to reprodce Imap delete problem. I can produce the move/copy mail to Local folders prob (bug 183766) And after that fails, if I try to batch delete some mesgs for Local folders, than I can see batch delete fail. was successful only once in reproducing imap batch delete fail. David, how come this only affects linux? why doesn't window or mac builds show this problem? I'll keep trying to find steps to produce but don't know successful i will be in verifying this bug is fixed.

Gary, the reason it mostly seems to affect linux is just luck of the draw. We were using an uninitialized local variable, so whatever happened to be on the stack when we used that var determined if it was a failure or not. Depending on your OS and/or compiler, you'd get different results.

I recompiled with debugging now. I tested the localfolder handling quite a bit and couldn't reproduce the problem. This might be hidden by the extreme slowdown of moz. I got the problems with imap folders, though. At the time this happened the console showed the following messages (repeated several times): ###!!! ASSERTION: Last delete did not complete: 'PR_FALSE', file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 Break: at file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 The fact that this isn't fixed isn't really surprising since in my imap handling no local folders are (should be) involved. I'm compiling a non-debug version of the trunk moz again and will try to use it again.

you can also download a real release trunk build tomorrow with the local folders fix. And like I said before, you can do an optimized build with assertions turned on, which should be reasonably fast, if it turns out that the non-optimized build masks the problem for local folders. this assertion is after the fact. The question is why didn't last delete finish. Once you get in this state, does get new mail get you out of the state? ###!!! ASSERTION: Last delete did not complete: 'PR_FALSE', file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 Break: at file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295

> And like I said before, you can do an optimized build with assertions > turned on, which should be reasonably fast, if it turns out that the > non-optimized build masks the problem for local folders. I kept optimizations enabled and it still is unacceptably slow. I append here the messages which were printed before the ones I've sent before: ###!!! ASSERTION: already copying a msg into this folder: '!mCopyState', file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 Break: at file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 2794 ###!!! ASSERTION: already copying a msg into this folder: '!mCopyState', file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 Break: at file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 2794

ah, now we're getting closer. I guess those are mail filters trying to move messages to local folders, since you weren't doing that in the UI? Is there anything before that on the console? I can try and simulate that in the debugger and see if we're sending the delete failed notification to the view in that case. I don't know why a debug optimized build would be so much slower on linux, so I can't help you there :-(

Is bug 63550 a dup of this one?

> I guess those are mail filters trying to move > messages to local folders, since you weren't doing that in the UI? Yes, can very well be. I haven't moved anything myself and I have 7 or 8 filters. > Is there anything before that on the console? There are tons of messages because of some GUI problems. This message is repeated dozens of times: ###!!! ASSERTION: nsDependentString must wrap only null-terminated strings: '!*aEndPtr', file ../../../dist/include/string/nsDependentString.h, line 86 Break: at file ../../../dist/include/string/nsDependentString.h, line 86 Another favorite: ###!!! ASSERTION: nsStandardURL not thread-safe: 'owningThread == NS_CurrentThread()', file /home/drepper/mozilla/xpcom/glue/nsDebug.cpp, line 533 Break: at file /home/drepper/mozilla/xpcom/glue/nsDebug.cpp, line 533 Beside these two messages the ones I see after startup are: CSS Error (chrome://messenger/skin/messageBody.css :52.6): Unknown namespace prefix 'html'. Selector expected. Ruleset ignored due to bad selector. mailCharsetLoadListener: ISO-8859-1 ###!!! ASSERTION: nsMsgProtocol::SetContentCharset: 'Not Reached', file /home/drepper/mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 556 Break: at file /home/drepper/mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 556 ^^^ This one is repeated several times, for different encodings. WARNING: Droping timer event because thread is dead, file /home/drepper/mozilla/xpcom/threads/nsTimerImpl.cpp, line 499 ^^^ !!! This one I haven}t reported before. WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 2794 ###!!! ASSERTION: nsStandardURL not thread-safe: 'owningThread == NS_CurrentThread()', file /home/drepper/mozilla/xpcom/glue/nsDebug.cpp, line 533 Break: at file /home/drepper/mozilla/xpcom/glue/nsDebug.cpp, line 533 ###!!! ASSERTION: already copying a msg into this folder: '!mCopyState', file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 Break: at file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 2794 ###!!! ASSERTION: already copying a msg into this folder: '!mCopyState', file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 Break: at file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 1645 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 2794 ###!!! ASSERTION: Last delete did not complete: 'PR_FALSE', file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 Break: at file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 ###!!! ASSERTION: Last delete did not complete: 'PR_FALSE', file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 Break: at file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 ###!!! ASSERTION: Last delete did not complete: 'PR_FALSE', file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 Break: at file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 ###!!! ASSERTION: Last delete did not complete: 'PR_FALSE', file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 Break: at file /home/drepper/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2295 > I can try and simulate that in the debugger and see if we're sending the delete failed notification to the view in that case.

Could bug 184576 be related?

>There are tons of messages because of some GUI problems. that's probably what's slowing you down. WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /home/drepper/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 2794 Are you sure you have my change to line 2793 of nsLocalMailFolder.cpp? Correct me if I'm wrong, but isn't that this code? : nsresult rv; nsCOMPtr<nsICopyMessageStreamListener> copyStreamListener = do_CreateInstance(NS_COPYMESSAGESTREAMLISTENER_CONTRACTID, &rv); NS_ENSURE_SUCCESS(rv,rv); before I checked in, this code looked like this: nsresult rv; nsCOMPtr<nsICopyMessageStreamListener> copyStreamListener = do_CreateInstance(NS_COPYMESSAGESTREAMLISTENER_CONTRACTID); NS_ENSURE_SUCCESS(rv,rv); and rv was unintialized and the above warning would get printed out. With my patch, the only way I can think that would fail is if you were out of memory, or the component mgr was messed up and unable to create objects.

I am currently running BuildID 2002120921 (trunk) and things are *really* bad - even when IMAP does not freeze, it crawls. IMHO this might deserve a "1.3a blocker" status.

I'm not sure why IMAP performance would have regressed since the imap change I made only affects the case where we have to queue urls, and that should be relatively rare - I'll update my tree to see if anything else has changed. Is everything slow? Do you have imap set up to check all folders for new mail?

> Is everything slow? After a short while - yes, all IMAP operations (view, delete, move, FCC save, header pane update on selecting a new folder, etc). It works normally for a very short while after Mozilla is started and after I switch offline and back online. But after couple of minutes, all IMAP operations start taking forever (minutes, or even more, sooner or later I give up waiting on some of them). This makes it absolutely unusable. NNTP seems OK (but haven't tested much). > Do you have imap set up to check all folders for new mail? Yes! I have user_pref("mail.check_all_imap_folders_for_new", true); I have 2 IMAP accounts with about 20 folders each, most of them are also selected for offline. I have the default limit of 5 connections per server. The problem definitely did not exist with 2002111118 and I believe it didn't exist with 2002112315 and did not exist (or was much smaller) in 2002120221. I can not be sure about the last two (I can check if necessary) since I was away and used them with IMAP server being in a remote location as opposed to being on a local network (is it possible that the problem is much worse when the IMAP server is much closer?).

> Are you sure you have my change to line 2793 of nsLocalMailFolder.cpp? Correct > me if I'm wrong, but isn't that this code? : There was definitely something fishy about the way I had the patch applied. I removed the entire file and update from CVS and after recompilation I now see no mail-related problems anymore. I'm using this moz for about 20 hours now. I consider the issue closed. Thanks. WRT the slowdown which somehow crept into this bug: I cannot reproduce it. But my imap server is local.

using commercial 2002-12-10-08-trunk on XP 2002-12-10-05-trunk on linux 2.2 2002-12-10-03-trunk on Mac 10.1.5 couldn't reproduce multiple delete problem in imap or Pop/local folders. I tried the only way I knew how to replicate the problem for Local folders (copy imap mesgs to local folder, then try to delete multiple mesgs) but since (bug 183766)was fixed that is no longer a vaild test case. Tried both migrated/new profiles. I am not noticing the slowness of imap folders but I don't have the pref set.

Yes, I turned off mail.check_all_imap_folders_for_new and it's now works normally (may still slow down later, of course, but it's definitely much better).

on 12-10 trunk linux 2.2 build I tried setting the pref mail.check_all_imap_folders_for_new on a imap account. And this is what I noticed. If I do download/sync and select some folders and go offline, no problems it works. if I go back online, Click GetMsgs button on toolbar and then do a download/sync now, it will kind of hang. Mouse turns into hourglass as something is processing but not going offline. David, i can file a new bug if you want on this.

my problem with moving multiple imap messages to local folders seems to be fixed now with today's build. yay!

Even without check_all_imap_folders_for_new the problem still exists if you select "Check this folder for new messages" (in Properties dlg of a folder) for a sufficient number of folders. Right now one of of the accounts I have 5 folder with this pref selected (+INBOX) and two of those folders now appear "stuck" (if I select the folder in the folders pane, both the folders pane and headers pane will get the "busy" cursor; even after I select one of the "stuck" folders, Mozilla still would not show me that the folder has new messages (that I know it has) - neither new headers nor updated message counts are shown). All other folders and all folders in another account (where I selected only two non-INBOX folders to be checked for new mail) are working normally...

Re: Comment #74 You just need to wait (w/o doing anything) in online mode until the new messages check happens for the first time. After that, most of the IMAP functionality (not just syncing for offline) will get stuck.

I downgraded to BuildID 2002120221 and as I expected (see comment #70) it does not seem to have this problem (but it did hang once as described in bug 184576).

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

Okay, I am having a similar problem, but it is much more limited. My bug (bug 184959) has been marked as a duplicate of this one. After I perform one delete operation (which works) of any number of messages, I can no longer delete in folders belonging to that server. 1.It is only one folder that breaks delete: pop server inbox 2.Deleting only (dragging to trash works) 3.Pop server (downloading all, not leaving any on server.) 4.Only delete is broken only for this server - another pop server works fine. 5.After delete breaks, I can no longer move mail to trash. Moving from inbox to other places has odd behavior - sometimes it works, sometimes it doesn't, sometimes odd things happen. 6.The delete operation works - the mail is gone from the inbox 7.There is no hanging - everything works but delete 8.Restarting allows me to delete once again I am using 2002121104 right now. This only happened recently (maybe beginning of December or so. Stacktrace is in bug 184959.

Another data point: I have the "unable to delete" problem. This generally occurs when I have sent a new message, and Mozilla was unable to copy the message to the Sent folder (bug 28211). The Sent problem occurs repeatedly after the 2nd or 3rd message send, and from then on until I restart Mozilla. Once the Sent problem occurs, the Delete problem occurs. Also, I am then unable to copy/move messages from any source to any target folder.

Hal: 2002121104 is almost a week old now. If you try to report - or comment to - bugs, please use a really current build. Additionally, try to delete your compreg.dat (ah, of course you don't need to do that as you never copy a new build over an old one, you always install the new build into a new folder as you should). Anyway, please retry in a new build. I had this until some time last week as well, and it appears to be fixed now. It should have been fixed on 2002-12-09 but you never know ;-)

I always have the problem of deleting emails with a trunk release of 14 december (don't have the full ID because I'm currently at work and this test was made yesterday night at home); under Win98 by the way. I delete some emails then suddently can't remove more email in my inbox. I see also that the problem begin with a display bug : can't display the message content when selecting a message in my inbox -> need to select another folder then reselect the inbox folder then the message display, but can't delete it anyway. I download a new release 3 or 4 times by week. But this problem never disappear for me since you work on the patch. Hope this helps.

Forget to mention that, since the last patch, the problem of not be able to move message from inbox to another folder has disappear for me.

Okay, in an effort to appease Robert Kaiser I have dutifully downloaded the latest nightly an instant before posting this message. I also diligently uninstalled and deleted not only the compreg.dat file, but the entire program tree after uninstalling. Bug is still present exactly as described in previous report. 8') Build 2002121708.

Hal, do you have it set such that deleting a message from your pop3 inbox deletes the message from the pop3 server?

bienvenu, No. Also "leave on server" is not checked.

I'm seeing a prob that I feel must be related to this: when I delete a msg with the "delete" key, it does appear to be deleted, but the next unread msg does not get loaded. The highlight moves down to the next unread msg, but the msg does not appear, even after several minutes. Moving up and down with the arrow keys causes the msg to appear immediately. Linux/x86, today's build 20021219. imap server on localhost [at least as far as moz sees it - really an ssh tunnel to a remote ssh server] I do have several folders with "check this folder for new messages" set, although problem also affects INBOX. Is this related? Merry Christmas.

shouldn't set m_deleting rows if the delete fails immediately since we might not get told it succeeded or failed later.

Further data to my Comment #88 : o I'm also seeing the severe imap crawl reported earlier. o The msgs really are being deleted; it's just the display of the next msg that's failing to load. o If all the next msgs are already read, problem does not occur; only occurs when next msg is unread.

Comment on attachment 109778 [details] [diff] [review] handle delete failing immediately r/sr=sspitzer

using 20020121908 trunk build on linux 2.2 not seeing Calum's problem. Course not using a imap server on localhost and don't have access to one. Works fine with imap though. No problems loading next unread mesg.

Comment on attachment 109778 [details] [diff] [review] handle delete failing immediately r=blizzard

this patch fixes the regressions I saw when other folders were configured for offline use. It also removes a few unused methods, and fixes a crash in biff when the sink is null.

Comment on attachment 109869 [details] [diff] [review] proposed fix for regressions sr=sspitzer

Same symptoms: I tried to block-mark and delete a bunch of e-mail and nothing happens. I then try to delete just one and again nothing happens. This is on Win98SE computer with Mozilla 1.3b (Gecko/20021220). This has happened a few times before during the last couple of months and I'm really ready to give up trying to use it as anything other than an experimental e-mail handler. I've had to remove Mozilla completely and then reinstall to get any deletion ability back. Not good. The old Netscape 4.xx series was so much more stable at e-mail handling. And Mozilla's crippled e-mail import/export ability aggravates things tremendously when dealing with problems like this.

Comment on attachment 109869 [details] [diff] [review] proposed fix for regressions checked in.

Comment on attachment 109778 [details] [diff] [review] handle delete failing immediately checked in.

Bernie, are you using imap or pop3? You might try tomorrow's build. Though if you have to reinstall instead of just shutting down and restarting before you can delete again, you're seeing a completely different problem.

Quick testing suggests bienvenu's checkins have cured all my problems as reported in Comment #88 and Comment #90.

With the latest patch (BuildID 2002122113 on Red Hat Linux 8.0) I no longer see the problems described in comment #68 and comment #70. Or at least, no issues noticed after running for 15 minutes with biff set for every minute and heck_all_imap_folders_for_new set to true whiuch is definitely much better that it used to be before. Thanks for the patch!

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

I'm still experiencing the symptoms I described above with build 2002122308.

the last patch caused a regression (see #186560), but david has a fix for it.

I'm going to mark this fixed, and deal with any remaining issues in other bugs. In particular, I've re-opened Hal Black's bug, which turned out to be a case of having two URI's to the INBOX with different case spellings.

using commercial trunk 2002-12-24-08-trunk on xp 2002-12-24-08-trunk on OS 10.1.2 2002-12-24-08-trunk on Linux 2.2 I see no problems deleting mesgs. Note that I really never could reproduce all the problems mentioned in this bug before David's fixes landed. But it seemed most of the reporters in this bug have confirmed their problems are fixed. But I did test the following: - imap (2 different imap servers: Netscape and cyrus), pop, Local folders - delete mesgs really fast from imap,pop,local folders as stated in comment 20 - tried test mesg in comment 24 (only works on Pop or Local) as it has invalid headers for imap - tried deleting mesgs with foreign chars - tried comment 8 for imap,pop,local folders - copying/moving multiple mesgs from inbox of my imap or pop acnt, then trying multiple deletes in imap,pop,local folders comment 41 Also don't see the problems with deleting mesg, then selecting next mesg bug: bug 186560 marking as verified.

I downloaded and installed the 12/24 Windows release (uninstalled and deleted the my previous Mozilla)and I still have the same symptoms: I block-mark several e-mails and can delete them successfully, but then I try to delete one more but can't. I exit out and go back in, and then I'm able to delete one e-mail before it stops working again. This is on a Win98se system. Don't think it's fixed....

Bernie, Check out bug 184959, sounds like you have those symptoms. I think this bug has something to do with imap servers in particular.

FYI, I've just opened a very similar bug (bug 187937). One single mail causing havoc, without any repeated delete action or whatever.

I just downloaded and installed the 1.3 release version of Mozilla and I checked to see if I could block-delete some e-mail and then try to delete some more afterwards. Unfortunately, this particular delete bug seems to be still present. To delete any more email, I have to exit out of Mozilla altogether and then go back to delete any further email. This is on a POP3 account. It's unclear when, why and how this started, but once it started, there seems to be no good way to fix it.