(In reply to Wayne Mery (:wsmwk) from comment #5)

With version 60, the crash rate has roughly tripled

It looks like version 68 crash rate is currently 4-5x higher than 60 (adjusted for percentage of users on both releases). Unfortunately I didn't document last year's crash rate numbers.

That said, it's not a topcrash - ranked #105 for version 68.3.1

(emailed one crash reporter, grigorov)

FYI encountered this crash in TB 82.0b2...
bp-a2e84fe4-26f2-44e0-9ad4-0a9140201028

Crash rate is now half what it was 6 months ago for both this crash and bug 1581017.

The decrease in crash rate begins in early November, which coincides with two events

1. turning up the knob to move version 68 users to version 78
2. shipping the 78.4.x series - 78.4.0 https://mzl.la/3dFNWPL, 78.4.1 https://mzl.la/3r7o4Tk , 78.4.3 https://mzl.la/3dFNWPL (78.4.2 did not ship IIRC)

Several crash patches land in 78.4.0 but ISTM none would impact this bug. But a possible explanation is the v78 crash rate might already be lower than 68 from an earlier patch that did not get uplifted to 68. That can't be assessed without comparing relative crash rates over time of each version, which crash-stats does not readily provide.

I also checked 6 months of beta crashes to attempt to find a timing - but no change. Ditto for bug 1581017.

(In reply to Richard Leger from comment #8)

FYI encountered this crash in TB 82.0b2...
bp-a2e84fe4-26f2-44e0-9ad4-0a9140201028

0 xul.dll MOZ_Z_inflate_table(<unnamed-tag>, unsigned short*, unsigned int, code**, unsigned int*, unsigned short*) modules/zlib/src/inftrees.c:236
1 xul.dll MOZ_Z_inflate(z_stream_s*, int) modules/zlib/src/inflate.c:949
2 xul.dll nsMsgCompressIStream::Read(char*, unsigned int, unsigned int*) comm/mailnews/base/src/nsMsgCompressIStream.cpp:159
3 xul.dll nsMsgLineStreamBuffer::ReadNextLine(nsIInputStream*, unsigned int&, bool&, nsresult*, bool) comm/mailnews/base/src/nsMsgLineBuffer.cpp:335
4 xul.dll nsImapProtocol::CreateNewLineFromSocket() comm/mailnews/imap/src/nsImapProtocol.cpp:4745
5 xul.dll nsImapServerResponseParser::GetNextLineForParser(char**) comm/mailnews/imap/src/nsImapServerResponseParser.cpp:83
6 xul.dll nsIMAPGenericParser::AdvanceToNextToken() comm/mailnews/imap/src/nsIMAPGenericParser.cpp:95
7 xul.dll nsImapServerResponseParser::ParseIMAPServerResponse(char const*, bool, char*) comm/mailnews/imap/src/nsImapServerResponseParser.cpp:184
8 xul.dll nsImapProtocol::FetchMessage(nsTString<char> const&, <unnamed-tag>, char const*, unsigned int, unsigned int, char*) comm/mailnews/imap/src/nsImapProtocol.cpp:3642
9 xul.dll nsImapProtocol::FetchTryChunking(nsTString<char> const&, <unnamed-tag>, bool, char*, unsigned int, bool) comm/mailnews/imap/src/nsImapProtocol.cpp:3692
10 xul.dll nsIMAPBodypart::GeneratePart(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:412
11 xul.dll nsIMAPBodypartLeaf::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:531
12 xul.dll nsIMAPBodypartMultipart::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:893
13 xul.dll nsIMAPBodypartMultipart::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:893
14 xul.dll nsIMAPBodypartMultipart::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:893
15 xul.dll nsIMAPBodypartMessage::Generate(nsIMAPBodyShell*, bool, bool) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:764
16 xul.dll nsIMAPBodyShell::Generate(char*) comm/mailnews/imap/src/nsIMAPBodyShell.cpp:227
17 xul.dll nsImapProtocol::ProcessSelectedStateURL() comm/mailnews/imap/src/nsImapProtocol.cpp:2773
18 xul.dll nsImapProtocol::ProcessCurrentURL() comm/mailnews/imap/src/nsImapProtocol.cpp:1792
19 xul.dll nsImapProtocol::ImapThreadMainLoop() comm/mailnews/imap/src/nsImapProtocol.cpp:1433
20 xul.dll nsImapProtocol::Run() comm/mailnews/imap/src/nsImapProtocol.cpp:1116

I assume this happens when fetching a new message and not when reading an existing message in offline store? Also, it's from a server using compression, e.g., gmail? If reproducible on a given server or message, does setting mail.server.default.use_compress_deflate false fix the problem?
Looks like array bounds are being violated deep down in the mozilla zlib code when "inflating" a compressed imap response.

Richard, do you still encounter this crash signature?

And like your bug 1333031, the crash rate here is about 50% less compared to 6 months ago.

(In reply to gene smith from comment #11)

I assume this happens when fetching a new message and not when reading an existing message in offline store?

It was not from offline store as my main imap account cache is disabled. If I submitted the report bp-a2e84fe4-26f2-44e0-9ad4-0a9140201028 I would have put a comment indicating the last steps prior crash if I notice it. Are you able to access such comment?

Also, it's from a server using compression, e.g., gmail? If reproducible on a given server or message, does setting mail.server.default.use_compress_deflate false fix the problem?

Not Gmail, but a Cyrus IMAP server (I think Gmail also use Cyrus), the crash was random and not reproducible at will.

Looks like array bounds are being violated deep down in the mozilla zlib code when "inflating" a compressed imap response.

Is decompression occurring on the fly or after message is downloaded? I am not sure how to check if the server use decompression would IMAP logs shows it? I do have some from previous bug issues.

(In reply to Wayne Mery (:wsmwk) from comment #12)

Richard, do you still encounter this crash signature?

Since the I have upgraded TB couple of times will check if report came back or not... keep you posted...

Is decompression occurring on the fly or after message is downloaded? I am not sure how to check if the server use decompression would IMAP logs shows it? I do have some from previous bug issues.

I guess you would say it happens on the fly since imap code in tb never see or has to deal with compressed data. It's all handled in the mozilla read and zlib library. All tb code does is enable it if it sees the capability COMPRESS=DEFLATE. Then it sends to the server a command called "COMPRESS DEFLATE" so you will see these in the log like this:

I/IMAP 0x7fb1768d6800:imap.gmail.com:A:SendData: 4 COMPRESS DEFLATE
D/IMAP ReadNextLine [rv=0x0 stream=0x7fb171c18ac0 nb=14 needmore=0]
I/IMAP 0x7fb1768d6800:imap.gmail.com:A:CreateNewLineFromSocket: 4 OK Success

Before this you will also see a capability response like this:

I/IMAP 0x7fb1768d6800:imap.gmail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ...

(In reply to gene smith from comment #15)

I guess you would say it happens on the fly since imap code in tb never see or has to deal with compressed data. It's all handled in the mozilla read and zlib library. All tb code does is enable it if it sees the capability COMPRESS=DEFLATE. Then it sends to the server a command called "COMPRESS DEFLATE" so you will see these in the log like this:
I/IMAP 0x7fb1768d6800:imap.gmail.com:A:SendData: 4 COMPRESS DEFLATE
(...)
I/IMAP 0x7fb1768d6800:imap.gmail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ...

Yes I see such lines in logs:

(...)
2021-01-09 16:07:11.876000 UTC - [Parent 9104: IMAP]: I/IMAP EATE-SPECIAL-USE URLAUTH URLAUTH=BINARY LOGINDISABLED COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE] Success (tls protection) SESSIONID=
<cyrus-(...)
(...)
2021-01-09 16:07:12.130000 UTC - [Parent 9104: IMAP]: I/IMAP 0000026C18757000:mail.****:A:SendData: 5 COMPRESS DEFLATE
(...)

Made contact with one crash reporter, Jassen. No useful info yet.

Just encountered in TB 91.11.0 on Windows 10 while browsing email in a sub-folder IMAP account... no cache... online mode...
bp-2916ff34-4676-426b-9ab9-be9220220711

Could be linked to high latency on the Internet connection that I currently encounter... email are slow to load in preview and when selecting some of them TB crashes...

Ping statistics for 62.3.75.133:
Packets: Sent = 18, Received = 18, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 85ms, Maximum = 336ms, Average = 189ms

No version 102 crashes, like

• Bug 1684266 - Crash in [@ ImapMessageSinkProxy::GetMessageSizeFromDB
• Bug 1649674 Crash in nsStreamConverter::OnDataAvailable (78+ edition) - imap thread and freed memory

Only one version 102 crash in past 6 months bp-86ac3c51-a240-446a-bbb4-527c90230118

There are rare version 102 crashes, but none newer, and no version 115 crashes