1873134 - Crash in [@ OOM | large | NS_ABORT_OOM | nsTSubstring<T>::AllocFailed | nsTSubstring<T>::Append | MimeRebuffer::IncreaseBuffer]

Status: NEW

(MailNews Core :: MIME, defect, P1)

Description

[Wayne Mery (:wsmwk)]

Crash rate increased with 122.0b1

Crash report: https://crash-stats.mozilla.org/report/index/986b8075-0e96-495b-9ff1-7022b0240104

MOZ_CRASH Reason: MOZ_CRASH(OOM)

Top 10 frames of crashing thread:

0  xul.dll  NS_ABORT_OOM  xpcom/base/nsDebugImpl.cpp:674
1  xul.dll  nsTSubstring<char>::AllocFailed  xpcom/string/nsTSubstring.h:1189
1  xul.dll  nsTSubstring<char>::Append  xpcom/string/nsTSubstring.cpp:858
2  xul.dll  MimeRebuffer::IncreaseBuffer  mailnews/mime/emitters/nsMimeRebuffer.cpp:17
3  xul.dll  nsMimeBaseEmitter::Write  mailnews/mime/emitters/nsMimeBaseEmitter.cpp:393
4  xul.dll  nsMimeHtmlDisplayEmitter::WriteBody  mailnews/mime/emitters/nsMimeHtmlEmitter.cpp:444
5  xul.dll  nsTSubstring<char>::~nsTSubstring  xpcom/string/nsTSubstring.h:326
5  xul.dll  mime_output_fn  mailnews/mime/src/mimemoz2.cpp
6  xul.dll  MimeOptions_write  mailnews/mime/src/mimei.cpp:1573
7  xul.dll  MimeObject_write  mailnews/mime/src/mimei.cpp:1601

Comment 1

[Magnus Melin [:mkmelin]]

I don't have any clues, sorry.

Comment 2

[Wayne Mery (:wsmwk)]

Attachment: history graph of OOM large crashes.png

OOM | large | xxxx crashes increase in early January

But in in 2023:

• OOM | small with MimeRebuffer::IncreaseBuffer on the stack on the other hand increase starting around 115.4.1/115.4.2
• OOM | small with nsMimeHtmlDisplayEmitter::WriteBody on the stack - the increase in the last week of October 2023 is much more obvious, also starting around 115.4.1/115.4.2

[edit]
Reporters in these OOM | small crashes start it started after update:

• bp-c4bc4f06-0cb5-4386-9078-e4d860231121 115.4.3
• bp-432ed3a2-f8b5-4212-9fa4-09fec0231122 115.4.3

Comment 3

[Wayne Mery (:wsmwk)]

OOM | large increases might be associated with Bug 1872849 folder corruption, because at least one of the crash reporter bp-4c3d6095-1691-4284-8ea6-3fb7c0240128 122.0b4 states "Suddenly my whole drive except for less than 1% was filled with something. After 2 days of working on it, I found that your [Gmail].spd subdirectory was occupying 390GB".

Comment 4

[Wayne Mery (:wsmwk)]

checkins:

• Version 122 is 14 checkins https://mzl.la/4c26pE0 (minus some categories unlikely to be related)
• 115.4.1 backend only https://mzl.la/3TjAbwC
• 115.4.2 backend only https://mzl.la/3IjO6fQ

Or we might assume bug 1719121 until proved otherwise?

Comment 5

[Makoto Kato [:m_kato]]

bp-4c3d6095-1691-4284-8ea6-3fb7c0240128 and bp-986b8075-0e96-495b-9ff1-7022b0240104 are x86 (32-bit) build even if CPU supports x86_64 (64-bit). If Thuderbird offers x86_64 build on x86_64 supported CPU, this will be resolved.

Comment 6

[Wayne Mery (:wsmwk)]

Still a #2 crash for beta, when counts for two crash signatures are combined.

Comment 7

[Wayne Mery (:wsmwk)]

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

Still a #2 crash for beta, when counts for two crash signatures are combined.

Which means this crash has not been improved by the patch in bug 1872849, which IS on 125.0b1 and newer betas.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Makoto Kato [:m_kato] from comment #5)

bp-4c3d6095-1691-4284-8ea6-3fb7c0240128 and bp-986b8075-0e96-495b-9ff1-7022b0240104 are x86 (32-bit) build even if CPU supports x86_64 (64-bit). If Thuderbird offers x86_64 build on x86_64 supported CPU, this will be resolved.

Still, half of crashes are users on 64bit OS and none of them are running 32bit Thunderbird

Comment 9

[Wayne Mery (:wsmwk)]

Version 91 and 102 crashes are OOM | large | NS_ABORT_OOM | nsTSubstring<T>::Append | MimeRebuffer::IncreaseBuffer(In reply to Wayne Mery (:wsmwk) from comment #0)

Crash rate increased with 122.0b1

Numbers-wise, crash rate at least doubled starting ~December 27/28.

Comment 10

[Wayne Mery (:wsmwk)]

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

Version 91 and 102 crashes are OOM | large | NS_ABORT_OOM | nsTSubstring<T>::Append | MimeRebuffer::IncreaseBuffer(In reply to Wayne Mery (:wsmwk) from comment #0)

Crash rate increased with 122.0b1

Numbers-wise, crash rate at least doubled starting ~December 27/28.

Actually a 10x increase