1742590 - If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs, @ MimeInlineTextHTMLParsed_parse_line, @ MimeInlineTextHTMLSanitized_parse_line

Reporter

Description

•

3 years ago

After the fixes for bug 1734847 landed in 95.0b4, running a Repair Folder operation on Inboxes and then attempting to shut down TB will cause what appears to be a huge memory leak / spike and subsequent hang that leads to a crash: https://crash-stats.thunderbird.net/report/bp-00f65de1-1f72-4ff9-a3c2-412621211123

Arthur K. (he/him)

Reporter

Updated

•

3 years ago

Summary: If running a Repair FOlder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog occurs → If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog occurs

Arthur K. (he/him)

Reporter

Comment 1

•

3 years ago

Assuming you have a slew of munged emails that's lead to a damaged Inbox, STR:

Using 95.0b4, start a Repair Folder operation on an Inbox (in my case, a GMail Inbox with 48k+ emails)
Let TB begin doing it's repair and within 10-15, try to close TB via File > Exit or by clicking the close [X] button at top right.
Task manager should slowly creep up in mem usage and TB will be in an out of a state of Not Responding and eventually crash

Was able to repro again just now: https://crash-stats.thunderbird.net/report/bp-bb7b0680-a326-4855-8d59-419a01211123

Magnus Melin [:mkmelin]

Comment 2

•

3 years ago

It's not (was not) the actual mails that were damaged, only the values in the index (.msf) were wrong.

Arthur K. (he/him)

Reporter

Comment 3

•

3 years ago

•

Edited

(In reply to Magnus Melin [:mkmelin] from comment #2)

It's not (was not) the actual mails that were damaged, only the values in the index (.msf) were wrong.

So if the mails are already mangled, that's permanent because what eventually comes down to the client (in my case via IMAP) is clean but gets mangled locally will eventually get sync'd back to the IMAP server?

Arthur K. (he/him)

Reporter

Comment 4

•

3 years ago

So I wanted to supplement my STR in comment 1 with something that might help repro this. I have now noticed that when a Folder Repair operation is happening and one is able to observe the "Downloading message X of Y in <mailbox name>" in the Status Bar, if you happen to click on a newly arrived email while the repair operation is happening, progress in the Status Bar will disappear but Task Manager will still show TB utilizing CPU.

Status Bar progress never comes back but it does increase the ability to cause the mem usage to go up and eventually crash TB. The only way to recover Status Bar progress being displayed is to File > Exit TB or End Task on the process and restart TB.

Magnus Melin [:mkmelin]

Comment 5

•

3 years ago

Locally mangled copy of an imap mail (if that would ever happen) won't ever get synced back to the server AFAIK. The mails are just cache basically.

Arthur K. (he/him)

Reporter

Comment 6

•

3 years ago

(In reply to Magnus Melin [:mkmelin] from comment #5)

Locally mangled copy of an imap mail (if that would ever happen) won't ever get synced back to the server AFAIK. The mails are just cache basically.

Thanks Magnus.

Arthur K. (he/him)

Reporter

Comment 7

•

3 years ago

I think there's a relationship between this one and bug 1740486.

Arthur K. (he/him)

Reporter

Updated

•

3 years ago

Summary: If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog occurs → If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs

Arthur K. (he/him)

Reporter

Comment 8

•

3 years ago

•

Edited

95.0b5 seems to be having a new crash on shutdown (@ nsMsgAttachmentData::~nsMsgAttachmentData) as opposed to 95.0b4.

Arthur K. (he/him)

Reporter

Comment 9

•

3 years ago

Here's a new crash report: https://crash-stats.thunderbird.net/report/bp-55167ff3-b01b-463f-9f3b-826561211130

Arthur K. (he/him)

Reporter

Comment 10

•

3 years ago

•

Edited

Tons more crashes:

Arthur K. (he/him)

Reporter

Comment 11

•

3 years ago

And in case you're wondering, it still happens in Safe mode as well.

Arthur K. (he/him)

Reporter

Updated

•

3 years ago

Summary: If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs → If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs, [@ MimeInlineTextHTMLParsed_parse_line ]

Arthur K. (he/him)

Reporter

Updated

•

3 years ago

Summary: If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs, [@ MimeInlineTextHTMLParsed_parse_line ] → If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs, @ MimeInlineTextHTMLParsed_parse_line

Wayne Mery (:wsmwk)

Updated

•

3 years ago

Depends on: 1740486

Arthur K. (he/him)

Reporter

Comment 12

•

3 years ago

Crash in 96.0b1 shows a slight change in "patched_BaseThreadInitThunk" line error location: https://crash-stats.thunderbird.net/report/bp-2190f8e7-1f08-44a2-a4a8-a474c1211207

Wayne Mery (:wsmwk)

Updated

•

3 years ago

URL: https://support.mozilla.org/en-US/que...

Arthur K. (he/him)

Reporter

Comment 13

•

3 years ago

Crash info at the above URL (https://crash-stats.thunderbird.net/report/bp-43da773c-ed95-4274-a828-cac7c1211212) lines up with my crashes too.

Arthur K. (he/him)

Reporter

Comment 14

•

3 years ago

Signature of crash on exit seems to have changed with 97.0b1. I am now seeing [@ MimeInlineTextHTMLSanitized_parse_line] > https://crash-stats.thunderbird.net/report/bp-e83aeb72-0fb0-45c4-b7ab-9e8c01220112

Also, in just the couple days of using 97.0b1, it seems to be crashing less on exit.Maybe just a fluke but 96.0 betas and early crashed on nearly every exit of the app.

Arthur K. (he/him)

Reporter

Updated

•

3 years ago

Summary: If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs, @ MimeInlineTextHTMLParsed_parse_line → If running a Repair Folder operation and attempting to shut down, crash @ mozilla::`anonymous namespace'::RunWatchdog / @ nsMsgAttachmentData::~nsMsgAttachmentData occurs, @ MimeInlineTextHTMLParsed_parse_line, @ MimeInlineTextHTMLSanitized_parse_line

Arthur K. (he/him)

Reporter

Comment 15

•

3 years ago

I went the nuclear route today and backed up my current profile, removed TB and all associated profile folders and started from scratch. Since this is a brand spanking new profile, I thought I wasn't going to be seeing and crashes on exit but I got a new crash signature ([@ static XPCWrappedNative::CallMethod ]): https://crash-stats.thunderbird.net/report/bp-0e43d45b-4e42-4093-9730-843d61220221

If you want me to open a new bug, let me know.

Arthur K. (he/him)

Reporter

Comment 16

•

3 years ago

This new crash looks like it might be similar to bug 1754369 or bug 1753968 apparently.

Magnus Melin [:mkmelin]

Comment 17

•

3 years ago

Yes that is bug 1754369.

Arthur K. (he/him)

Reporter

Comment 18

•

3 years ago

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1740486#c19

Magnus Melin [:mkmelin]

Comment 19

•

3 years ago

Arthur: how is this in current daily (or beta)?
It seems to work fine for me.

Arthur K. (he/him)

Reporter

Comment 20

•

3 years ago

(In reply to Magnus Melin [:mkmelin] from comment #19)

Arthur: how is this in current daily (or beta)?
It seems to work fine for me.

It works fine...after having completely re-done my TB profile from scratch. I would guess if I had not, I'd still be stuck in the mire. What I did in comment 18 fixed this so closing as WFM.

This issue may come back once people upgrade from 91 ESR to 102 ESR though so keep your eyes peeled. No one's yet to figure out what change between 91 and 100b is causing this, IMHO, profile corruption.

Status: NEW → RESOLVED

Closed: 3 years ago

Resolution: --- → WORKSFORME