Open Bug 1534119 Opened 7 months ago Updated Last month

Crash in nsImapProtocol::HandleMessageDownLoadLine

Categories

(MailNews Core :: Networking: IMAP, defect, critical)

x86
All
defect
Not set
critical

Tracking

(Not tracked)

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: crash, testcase-wanted)

Crash Data

+++ This bug was initially created as a clone of Bug #1444389 (fixed in 60.3.0) +++ -- which was speculated to perhaps related to bug 1264302 (reported for TB38) / bug 1216951 (fixed in TB60) and friends.

bug 1444389 adds a check for null line but the crashing continues. In fact the crash rate increases as more users adopt version 60.x per graph https://crash-stats.mozilla.com/signature/?product=Thunderbird&signature=nsImapProtocol%3A%3AHandleMessageDownLoadLine&date=%3E%3D2018-11-10T11%3A29%3A00.000Z&date=%3C2019-03-10T11%3A29%3A00.000Z#graphs

bp-f3a9a798-86fa-4c1b-979b-d95ff0190308 66 beta

bp-76aa5b6f-9176-412f-b1ba-54ad10190203 60.5.0 A per earlier cresh report there is one email with 18 attachments (17 photos and one rtf file which in aggregate is about 12Mb in size) which is is attempting to download from Yahoo mail and it ceashed every time. Is there a hard limit in the number of attachments or file size in Mozilla Thunderbird as to why it stuggles with this email?

0 xul.dll nsImapProtocol::HandleMessageDownLoadLine(char const*, bool, char*) comm/mailnews/imap/src/nsImapProtocol.cpp:3997
1 xul.dll nsIMAPBodypart::GenerateBoundary(nsIMAPBodyShell*, bool, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:472
2 xul.dll nsIMAPBodypartMultipart::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:983
3 xul.dll nsIMAPBodypartMessage::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:842
4 xul.dll nsIMAPBodyShell::Generate(char*) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:263
5 xul.dll nsImapProtocol::ProcessSelectedStateURL() comm/mailnews/imap/src/nsImapProtocol.cpp:2759
6 xul.dll nsImapProtocol::ProcessCurrentURL() comm/mailnews/imap/src/nsImapProtocol.cpp:1784
7 xul.dll nsImapProtocol::ImapThreadMainLoop() comm/mailnews/imap/src/nsImapProtocol.cpp:1403
8 xul.dll nsImapProtocol::Run() comm/mailnews/imap/src/nsImapProtocol.cpp:1062

bp-76aa5b6f-9176-412f-b1ba-54ad10190203 60.5.3
0 xul.dll nsImapProtocol::HandleMessageDownLoadLine(char const*, bool, char*) comm/mailnews/imap/src/nsImapProtocol.cpp:3997
1 xul.dll nsIMAPBodypart::GenerateEmptyFilling(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:509
2 xul.dll nsIMAPBodypartLeaf::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:591
3 xul.dll nsIMAPBodypartMultipart::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:985
4 xul.dll nsIMAPBodypartMessage::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:842
5 xul.dll nsIMAPBodyShell::Generate(char*) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:263
6 xul.dll nsImapProtocol::ProcessSelectedStateURL() comm/mailnews/imap/src/nsImapProtocol.cpp:2687
7 xul.dll nsImapProtocol::ProcessCurrentURL() comm/mailnews/imap/src/nsImapProtocol.cpp:1784
8 xul.dll nsImapProtocol::ImapThreadMainLoop() comm/mailnews/imap/src/nsImapProtocol.cpp:1403
9 xul.dll nsImapProtocol::Run() comm/mailnews/imap/src/nsImapProtocol.cpp:1062

Wayne, the last one you quoted is for 60.5.0, but here is one for 60.5.3: bp-c5a965fa-ce5c-462e-9a40-52d400190310.

It crashes at comm/mailnews/imap/src/nsImapProtocol.cpp:3997 which is:

  // if this line is for a different message, or the incoming line is too big
  if (((m_downloadLineCache->CurrentUID() != GetServerStateParser().CurrentResponseUID())  <== 3997
       && !m_downloadLineCache->CacheEmpty()) ||                                     <= also 3997, I wrapped it.
      (m_downloadLineCache->SpaceAvailable() < lineLength + 1) )
    FlushDownloadCache();

So we're dealing with a case with lots of data, like one reporter said, 12 MB with various attachments. So it looks like m_downloadLineCache got free'ed somehow since the crash shows invalid memory: 0xe5e5e5e9.

So it would be good to reproduce it. Meanwhile I spotted something fishy, patch coming.

(In reply to Jorg K (GMT+1) from comment #1)

Wayne, the last one you quoted is for 60.5.0, but here is one for 60.5.3: bp-c5a965fa-ce5c-462e-9a40-52d400190310.

Yes - I clearly label them as such and offer them as data for comparison. :) Whether it helps, is related, or not related, is something which can be determined later.

See Also: → 1534124

Richard's from bug 1505660 ... bp-9d9da253-2cbf-4896-8864-4542e0190115 bug 1534119 [@ nsImapProtocol::HandleMessageDownLoadLine ] - not actively using Thunderbird

Richard, do you have more for us?

Flags: needinfo?(richard.leger)

Since 15/01/2019 I had only three crashes...

bp-8a14849d-581b-435b-97b6-6f4400190318 18/03/2019, 10:29
bp-830c1844-cf6a-48c4-b84b-2cb650190302 02/03/2019, 16:58
bp-ce49864b-66cb-4f0b-8626-f66580190128 28/01/2019, 11:11

I would not recall what caused them... but should be indicated in the submission report for the two last (in the list)... the 18/08 was pending submission so I submitted it just now... do not recall what caused it...

Is that what you wanted?

Flags: needinfo?(richard.leger)

(In reply to Richard Leger from comment #4)

Since 15/01/2019 I had only three crashes...

bp-8a14849d-581b-435b-97b6-6f4400190318 [@ SkBitmapCache::PrivateDeleteRec ]
bp-830c1844-cf6a-48c4-b84b-2cb650190302 [@ mozilla::net::nsLoadGroup::AddRequest ]
bug 1508649 - bp-ce49864b-66cb-4f0b-8626-f66580190128 [@ shutdownhang | _PR_MD_WAIT_CV | PR_Wait | PR_CWait | nsMsgCopy::DoCopy ]

(In reply to Jorg K (GMT+2) (reduced availability 14-19 of Sept.) from comment #1)

... I spotted something fishy, patch coming.

Did this (patch) get spun off to another bug?

Flags: needinfo?(jorgk)

Yes, it did, bug 1534124. I should have noted it here, sorry.

Flags: needinfo?(jorgk)
You need to log in before you can comment on or make changes to this bug.