After installing JunQuilla, selecting all messages in a folder (~23000) and marking them as non-spam via the context menu crashes Thunderbird (9.0.1, JQ 1.0.2), leaves other folders in an inconsistent state. Can't see what TB wants to ship to Mozilla, and it doesn't ask me for further details, anyway.

(In reply to a_geek from comment #0) > After installing JunQuilla, selecting all messages in a folder (~23000) and > marking them as non-spam via the context menu crashes Thunderbird (9.0.1, JQ So this means that JunQuilla is the reason for the crash. I suppose.

A_geek can we have a crash ID please ? (see http://support.mozillamessaging.com/en-US/kb/mozilla-crash-reporter#w_viewing-crash-reports) ?

had you done this without junquilla, and not crashed? (I'm guessing junquilla isnot related)

probably going to end up being a duplicate of a bug tagged [bulkoperations] in the whiteboard

a_geek, this happens for imap account or pop3?

This is an IMAP account. I don't use POP3 anymore.

(In reply to a_geek from comment #0) > After installing JunQuilla, selecting all messages in a folder (~23000) and > marking them as non-spam via the context menu crashes Thunderbird (9.0.1, JQ > 1.0.2), leaves other folders in an inconsistent state. Crash itself is may be same phenomenon as bug 583365, "kill by memory size". Does your "After installing JunQuilla" implies that no crash/no memory related problem occurred when (~23000) mails were marked as Non-Junk without JunQuilla? What phenomenon do you call by "leaves other folders in an inconsistent state"? Tb already crashed, so other folders is irrelevant, isn't it? Or phenomenon after restart of Tb followed by the crash? "Mark as Junk" or "Mark as Non-Junk" consists of; (A) Selection of many mails at thread pane (B) Bayesian Filter processing for marking as Junk/Non-Junk (C) Move from Inbox to Junk, or move from Junk to Inbox == (C-1) Copy from Inbox to Junk or copy from Junk to Inbox + (C-2) Delete at Inbox or Junk Bug 583365 is for problem of "large memory usage by (A)" + "very large memory usage in (C) due to very large memory consumpsion by (C-2)" and problem of "Virual memory size is not decreased after end of process". a_geek@web.de(bug opener), can you check step by step memory usage by Tb in (A) and (B) separately? (1) Disable Junk Move (2) Select 100 mails, 500 mails, 1000 mails, ... (3) Mark As Junk : 100 mails, 500 mails, 1000 mails, ... Mark As Non-Junk : 100 mails, 500 mails, 1000 mails, ... Stop before crash starts, please. Is used memory size(Virtual Memory, Real Memory) O(number of marked mails)? If Tb's meory size is very large even after process ends, is memry size(Virtual Memory) of Tb reduced by next? (3) Open new Tb Window(account/folder context menu, Open) (4) Close old Tb Window.

I have now copied the mailbox to a new folder, so it doesn't matter too much if I wreak some havoc on that copy. With JunQuilla enabled copying those ~23.000 messages from the original mailbox to a completely new folder crashed TB after significant runtime. After disabling JunQuilla, I was able to copy the messages (resulting in a few thousand duplicates) after clicking away some warnings about an "unresponsive script". TB didn't exceed ~2.5 gigs of memory usage, but does use 100% of one of my cores on a 945 for almost than 19 minutes of cpu time (as seen in 'htop') now, without showing any signs of releasing the cpu or memory. TB is currently rather unresponsive. Before I started the copy, TB used some 700MB. I already had "Junk move" disabled. Memory usage is currently 2249M 1785M 33648 (VIRT RES SHR). By "leaves folders in inconsistent state", I mean that sometimes, after a crash, a folder looks broken. I.e., there may be empty lines displayed for what should be a message, and/or clicking a line does not display a message, but an empty message pane after restarting TB. To fix it, I have to go to the context menu of the affected folder and, select "Properties, then click "Repair folder". This occured to me on folders I didn't have open at the time (all IMAP over here). To be continued. For specific test results etc., I intend to copy the folder to a different profile so as to not further mess up my junk settings on my work account.

One more bit: Doing the "open new window, close old window" dance made the memory usage drop abruptly to 1908M 386M 34632.

I installed JunQuilla to small profile(Yahoo! IMAP+Gmail IMAP+Local Folders only), with Tb 9.0.1. Quick check result around JunQuilla. (A) Available JunQuilla Options. > Maximum token count: 300000 > Default > mailnews.bayesian_spam_filter.junk_maxtokens = 100000 > After JunQuilla install > mailnews.bayesian_spam_filter.junk_maxtokens = 300000 > Junk threshold : 90 > Uncertain folders > [Add] [Remove] (B) virtualFolders.dat entry added by JuQuilla. Condition of "Junk Percent" is standard one. > uri=imap://boyacky%40rocketmail.com@imap.mail.yahoo.com/INBOX/Uncertain > scope=imap://boyacky%40rocketmail.com@imap.mail.yahoo.com/INBOX > terms=AND (junk percent,is greater than,9) AND (junk percent,is less than,91) > searchOnline=false > uri=imap://yatter.king%40gmail.com@imap.googlemail.com/INBOX/Uncertain > scope=imap://yatter.king%40gmail.com@imap.googlemail.com/INBOX > terms=AND (junk percent,is greater than,9) AND (junk percent,is less than,91) > searchOnline=false > uri=mailbox://nobody@Local%20Folders/Inbox/Uncertain > scope=mailbox://nobody@Local%20Folders/Inbox > terms=AND (junk percent,is greater than,9) AND (junk percent,is less than,91) > searchOnline=false (C) Added thread pane column by JunQuilla. "colJunkPercent":{"visible":false,"ordinal":"19"} "colJunkStatusPlus":{"visible":false,"ordinal":"21"} Additional overhead by JunQuilla looks; (i) Required virtual memory may be increased by increased maxtokens. mailnews.bayesian_spam_filter.junk_maxtokens = 100000 -> 300000 (ii) Added processes for new colJunkPercent and colJunkStatusPlus. (iii) Virtual folder process for new "Inbox/Uncertain" folder when the "Uncertain" folder is clicked(opened). (Off-Topic) Another observations. (a) Yahoo! IMAP doesn't support Junk/NonJunk flag. So, Junk mark is not shown in Junk folder after Junk Move. (b) Gmail IMAP doesn't support Junk flag(rejects it). NonJunk only is supported. So, Junk mark is not shown in Junk folder after Junk Move. Yahoo! IMAP has "Bulk Mail" and Gmail IMAP has [Gmail]/Spam for Junk mail reporting and sever side Junk filtering is already active and server side Message Filtering is also available. I think users are better to disable Tb side Junk filtering if users use such modern IMAP servers.

Here's the latest crash id from when I tried to copy the emails: bp-f0762536-b855-4893-9790-b79ec2120130

signature of nsImapMailFolder::CopyMessagesOffline makes this a duplicate