Closed Bug 544799 Opened 14 years ago Closed 14 years ago

Two Thunderbird instances talking to the same (Dreamhost) IMAP account, both with move filters active, eventual crash

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 537551

People

(Reporter: asuth, Unassigned)

Details

When I use Thunderbird from home and come back to the office with a comm-1.9.2 debug build, I see hundreds of these.  I explicitly force new mail retrieval on the non-crashing build because it's a laptop coming out from suspend; I expect this factors into why it's always the (idle) office build that dies.

###!!! ASSERTION: invalid array index: 'i < Length()', file ../../../mozilla/dist/include/nsTArray.h, line 317


I also see a few of these:

###!!! ASSERTION: OnDataAvailable implementation consumed no data: 'Error', file /home/visbrero/rev_control/hg/comm-1.9.2/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 529
###!!! ASSERTION: unknown error, but don't alert user.: 'errorID != UNKNOWN_ERROR', file /home/visbrero/rev_control/hg/comm-1.9.2/mailnews/base/util/nsMsgProtocol.cpp, line 439


Eventually followed up by a crash.  addr2line claims on my most recent crash dump that it was the following:

nsTArray<unsigned int>::RemoveElementsAt(unsigned int, unsigned int)
mailnews/imap/src/../../../mozilla/dist/include/nsTArray.h:665

nsTArray<unsigned int>::RemoveElementAt(unsigned int)
mailnews/imap/src/../../../mozilla/dist/include/nsTArray.h:670

nsImapFlagAndUidState::ExpungeByIndex(unsigned int)
mailnews/imap/src/nsImapFlagAndUidState.cpp:200

nsImapServerResponseParser::numeric_mailbox_data()
mailnews/imap/src/nsImapServerResponseParser.cpp:1040

nsImapServerResponseParser::response_data()
mailnews/imap/src/nsImapServerResponseParser.cpp:756

nsImapServerResponseParser::ParseIMAPServerResponse(char const*, int, char*)
mailnews/imap/src/nsImapServerResponseParser.cpp:244

nsImapProtocol::ParseIMAPandCheckForNewMail(char const*, int)
mailnews/imap/src/nsImapProtocol.cpp:1863

nsImapProtocol::EndIdle(int)
mailnews/imap/src/nsImapProtocol.cpp:7491

nsImapProtocol::ProcessCurrentURL()
mailnews/imap/src/nsImapProtocol.cpp:1530

nsImapProtocol::ImapThreadMainLoop()
mailnews/imap/src/nsImapProtocol.cpp:1363

nsImapProtocol::Run()
mailnews/imap/src/nsImapProtocol.cpp:1064


This seems to happen pretty reliably for me.  I'll see about getting an IMAP trace and call stacks for the assertions.
(In reply to comment #0)
> When I use Thunderbird from home and come back to the office (snip)

PC is suspended when move from home to office? Tb is running while suspending?
If so, it's worse than simple suspend/reasume or sleep/wake-up case, because more events happen simultaneously:
  a. Network interface loss due power off, and it's recovery
  b. DNS server change
  c. IP address change of PC by DHCP due to location change
  d. Connection loss with IMAP server while IDLE is active
  e. IMAP server access due to "check new messages for every NNN minutes"
  f. etc.
Tb has problems around IDLE when sleep/wake-up, and some reorters said "disabling IDLE command use" was effective workaround, although problem due to c. still remained.
Recovery from a./d. looks to work if IDLE is disabled, but recovery from c. looks to fail and "work offline->work online" seems to be required.

Will "disabling IDLE command use" reduce frequency of problem?
To be clear, the office and home machines are separate machines, each running a copy of Thunderbird; that's why the subject mentions two thunderbird instances.

No need to QA this WADA (although your effort is appreciated); I'll either fix this myself or hand the bug to bienvenu on a platter.  I filed the bug for my own tracking and in case it jogs bienvenu's memory enough to save me doing the extra work.
Sounds like this bug, which has a fix awaiting sr - https://bugzilla.mozilla.org/show_bug.cgi?id=537551
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.