Closed Bug 646168 Opened 14 years ago Closed 10 months ago

crash (shift-del) deleting/moving mail in normal or Unified Folders view? [@ nsMsgXFViewThread::RemoveChildHdr] via nsMsgSearchDBView::OnHdrDelete - m_view is already destroyed or invalid

Categories

(MailNews Core :: Backend, defect, P1)

x86
All

Tracking

(thunderbird_esr115+ verified, thunderbird121 wontfix, thunderbird122? wontfix, thunderbird123 wontfix)

RESOLVED FIXED
124 Branch
Tracking Status
thunderbird_esr115 + verified
thunderbird121 --- wontfix
thunderbird122 ? wontfix
thunderbird123 --- wontfix

People

(Reporter: wsmwk, Assigned: welpy-cw)

References

Details

(Keywords: crash, topcrash-thunderbird, Whiteboard: [TM 115.9.0])

Crash Data

Attachments

(3 files)

crash [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] from crash-stats. nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*) has the same stack this module has many crashes sigs (at least 4) per https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&field0-0-0=short_desc&bug_severity=critical&bug_severity=major&bug_severity=normal&type0-0-1=substring&field0-0-1=keywords&type1-0-1=substring&value1-0-1=backend&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&value1-0-0=virtual%20saved%20XFView&longdesc=virtual%20XFView&value0-0-1=crash&type0-0-0=anywordssubstr&value0-0-0=crash%20segfault&field1-0-0=short_desc&product=MailNews%20Core&product=Thunderbird&longdesc_type=anywordssubstr&field1-0-1=component 262af427-7dde-4bf6-9846-c45d62110329 EXCEPTION_ACCESS_VIOLATION_READ 0x0 0 @0x0 1 thunderbird.exe nsMsgXFViewThread::RemoveChildHdr mailnews/base/src/nsMsgXFViewThread.cpp:346 2 thunderbird.exe nsMsgSearchDBView::OnHdrDeleted mailnews/base/src/nsMsgSearchDBView.cpp:266 3 thunderbird.exe nsMsgDatabase::NotifyHdrDeletedAll mailnews/db/msgdb/src/nsMsgDatabase.cpp:724 4 thunderbird.exe nsMsgDatabase::DeleteHeader mailnews/db/msgdb/src/nsMsgDatabase.cpp:1810 5 thunderbird.exe nsMsgDatabase::DeleteMessages mailnews/db/msgdb/src/nsMsgDatabase.cpp:1753 6 thunderbird.exe nsImapMailFolder::CopyMessagesOffline mailnews/imap/src/nsImapMailFolder.cpp:7178 7 thunderbird.exe nsImapMailFolder::CopyMessages mailnews/imap/src/nsImapMailFolder.cpp:7336 8 thunderbird.exe nsMsgCopyService::DoNextCopy mailnews/base/src/nsMsgCopyService.cpp:321 9 thunderbird.exe nsMsgCopyService::DoCopy mailnews/base/src/nsMsgCopyService.cpp:263 10 thunderbird.exe nsMsgCopyService::CopyMessages mailnews/base/src/nsMsgCopyService.cpp:531 11 thunderbird.exe nsImapMailFolder::DeleteMessages mailnews/imap/src/nsImapMailFolder.cpp:2405 12 thunderbird.exe nsMsgSearchDBView::ProcessRequestsInOneFolder mailnews/base/src/nsMsgSearchDBView.cpp:1097 13 thunderbird.exe nsMsgSearchDBView::DeleteMessages mailnews/base/src/nsMsgSearchDBView.cpp:908 14 thunderbird.exe nsMsgDBView::ApplyCommandToIndices mailnews/base/src/nsMsgDBView.cpp:2726 15 thunderbird.exe nsMsgDBView::DoCommand mailnews/base/src/nsMsgDBView.cpp:2393 16 thunderbird.exe nsMsgSearchDBView::DoCommand mailnews/base/src/nsMsgSearchDBView.cpp:807 nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*) bpf913b143-3f4f-490c-9441-2746d2110329 EXCEPTION_ACCESS_VIOLATION_EXEC 0x206f6f74 0 @0x206f6f74 1 thunderbird.exe nsMsgXFViewThread::RemoveChildHdr mailnews/base/src/nsMsgXFViewThread.cpp:346 2 thunderbird.exe nsMsgSearchDBView::OnHdrDeleted mailnews/base/src/nsMsgSearchDBView.cpp:266 3 thunderbird.exe nsMsgDatabase::NotifyHdrDeletedAll mailnews/db/msgdb/src/nsMsgDatabase.cpp:724 4 thunderbird.exe nsMsgDatabase::DeleteHeader mailnews/db/msgdb/src/nsMsgDatabase.cpp:1810 5 thunderbird.exe nsMsgDatabase::DeleteMessages mailnews/db/msgdb/src/nsMsgDatabase.cpp:1753 6 thunderbird.exe nsImapMailFolder::CopyMessagesOffline mailnews/imap/src/nsImapMailFolder.cpp:7178 7 thunderbird.exe nsImapMailFolder::CopyMessages mailnews/imap/src/nsImapMailFolder.cpp:7336 8 thunderbird.exe nsMsgCopyService::DoNextCopy mailnews/base/src/nsMsgCopyService.cpp:321 9 thunderbird.exe nsMsgCopyService::DoCopy mailnews/base/src/nsMsgCopyService.cpp:263 10 thunderbird.exe nsMsgCopyService::CopyMessages mailnews/base/src/nsMsgCopyService.cpp:531 11 thunderbird.exe nsImapMailFolder::DeleteMessages mailnews/imap/src/nsImapMailFolder.cpp:2405 12 thunderbird.exe nsMsgSearchDBView::ProcessRequestsInOneFolder mailnews/base/src/nsMsgSearchDBView.cpp:1097 13 thunderbird.exe nsMsgSearchDBView::DeleteMessages mailnews/base/src/nsMsgSearchDBView.cpp:908 14 thunderbird.exe nsMsgDBView::ApplyCommandToIndices mailnews/base/src/nsMsgDBView.cpp:2726 15 thunderbird.exe nsMsgDBView::DoCommand mailnews/base/src/nsMsgDBView.cpp:2393 16 thunderbird.exe nsMsgSearchDBView::DoCommand mailnews/base/src/nsMsgSearchDBView.cpp:807
hmm, I guess m_view is null - not sure how that can happen.
(In reply to comment #1) > hmm, I guess m_view is null - not sure how that can happen. is bug 526935 the same issue? (no significant crash reporter emails available to work with)
Blocks: 526935
Crash Signature: [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)]
Wayne, In response to your request for the information to be entered here instead of just E-mails: The first instance I selected four E-mails to move, the only other time it has happened it was a single message. I am using "Unified Folders". Jon
Crash Signature: [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] → [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)]
Summary: crash [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)], [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] → crash deleting mail [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)], [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)]
Crash Signature: [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] → [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr ]
OS: Windows Vista → All
Summary: crash deleting mail [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)], [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] → crash deleting mail in Unified Folders view? [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)], [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)]
(In reply to David :Bienvenu from comment #1) > hmm, I guess m_view is null - not sure how that can happen. the reporter of bp-98c884ff-a16e-4194-b669-9d07e2130701 says "Just deactivated Thunderbird-Conversations Add-On some minutes ago, then moved some Inbox-Mails into local folders. Since then no such problems". Thunderbird-Conversations does not however correlate in the other crashes looked at. For example bp-01f14752-3a2f-4c56-948f-618a62130714 and bp-1482632b-3749-4f15-b56c-6b2352130701
(In reply to Wayne Mery (:wsmwk) from comment #5) > (In reply to David :Bienvenu from comment #1) > > hmm, I guess m_view is null - not sure how that can happen. > > the reporter of bp-98c884ff-a16e-4194-b669-9d07e2130701 (humbug) says "Just > deactivated Thunderbird-Conversations Add-On some minutes ago, then moved > some Inbox-Mails into local folders. Since then no such problems".
topcrash in TB24 bp-f05dcaff-1383-436a-b0f1-ca74f2140312 0 xul.dll nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr *,nsIDBChangeAnnouncer *) mailnews/base/src/nsMsgXFViewThread.cpp 1 xul.dll nsMsgSearchDBView::OnHdrDeleted(nsIMsgDBHdr *,unsigned int,int,nsIDBChangeListener *) mailnews/base/src/nsMsgSearchDBView.cpp 2 xul.dll nsMsgDatabase::NotifyHdrDeletedAll(nsIMsgDBHdr *,unsigned int,int,nsIDBChangeListener *) mailnews/db/msgdb/src/nsMsgDatabase.cpp 3 xul.dll nsMsgDatabase::DeleteHeader(nsIMsgDBHdr *,nsIDBChangeListener *,bool,bool) mailnews/db/msgdb/src/nsMsgDatabase.cpp 4 xul.dll nsMsgDatabase::DeleteMessages(unsigned int,unsigned int *,nsIDBChangeListener *) mailnews/db/msgdb/src/nsMsgDatabase.cpp 5 xul.dll nsImapMailFolder::CopyMessagesOffline(nsIMsgFolder *,nsIArray *,bool,nsIMsgWindow *,nsIMsgCopyServiceListener *) mailnews/imap/src/nsImapMailFolder.cpp 6 xul.dll nsImapMailFolder::CopyMessages(nsIMsgFolder *,nsIArray *,bool,nsIMsgWindow *,nsIMsgCopyServiceListener *,bool,bool) mailnews/imap/src/nsImapMailFolder.cpp 7 xul.dll nsMsgCopyService::DoNextCopy() mailnews/base/src/nsMsgCopyService.cpp ehsan@13324 303 for (uint32_t childIndex = 0; childIndex < m_keys.Length(); childIndex++) bienvenu@774 304 { bienvenu@774 305 if (m_keys[childIndex] == msgKey && m_folders[childIndex] == msgFolder) bienvenu@774 306 { ehsan@13324 307 uint8_t levelRemoved = m_keys[childIndex]; bienvenu@774 308 // Adjust the levels of all the children of this header bienvenu@774 309 nsMsgViewIndex i; bienvenu@774 310 for (i = childIndex + 1; bienvenu@774 311 i < m_keys.Length() && m_levels[i] > levelRemoved; i++) bienvenu@774 312 m_levels[i] = m_levels[i] - 1; bienvenu@774 313 bienvenu@774 314 m_view->NoteChange(childIndex + 1, i - childIndex + 1, bienvenu@774 315 nsMsgViewNotificationCode::changed);
I just noticed that this happens with imap(?) I am using TB for POP3, and do not use unified view, so I did not notice this problem on my PCs. But investigating imap angle may be a way to go IMHO.
bp-4c06d1f5-1c95-412f-8780-a17472140814 FWIW, I was moving messages from a unified inbox view to a folder. The only accounts I have are IMAP.
(In reply to Adam Roach [:abr] from comment #9) > bp-4c06d1f5-1c95-412f-8780-a17472140814 > > FWIW, I was moving messages from a unified inbox view to a folder. The only > accounts I have are IMAP. abr's stack 0 XUL nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*) mailnews/base/src/nsMsgXFViewThread.cpp 1 XUL nsMsgSearchDBView::OnHdrDeleted(nsIMsgDBHdr*, unsigned int, int, nsIDBChangeListener*) mailnews/base/src/nsMsgSearchDBView.cpp 2 XUL nsMsgDatabase::NotifyHdrDeletedAll(nsIMsgDBHdr*, unsigned int, int, nsIDBChangeListener*) mailnews/db/msgdb/src/nsMsgDatabase.cpp 3 XUL nsMsgDatabase::DeleteHeader(nsIMsgDBHdr*, nsIDBChangeListener*, bool, bool) mailnews/db/msgdb/src/nsMsgDatabase.cpp 4 XUL nsMsgDatabase::DeleteMessages(unsigned int, unsigned int*, nsIDBChangeListener*) mailnews/db/msgdb/src/nsMsgDatabase.cpp 5 XUL nsImapMailFolder::CopyMessagesOffline(nsIMsgFolder*, nsIArray*, bool, nsIMsgWindow*, nsIMsgCopyServiceListener*) mailnews/imap/src/nsImapMailFolder.cpp 6 XUL nsImapMailFolder::CopyMessages(nsIMsgFolder*, nsIArray*, bool, nsIMsgWindow*, nsIMsgCopyServiceListener*, bool, bool) mailnews/imap/src/nsImapMailFolder.cpp 7 XUL _ZThn56_N16nsImapMailFolder12CopyMessagesEP12nsIMsgFolderP8nsIArraybP12nsIMsgWindowP25nsIMsgCopyServiceListenerbb mailnews/imap/src/nsImapMailFolder.cpp 8 XUL nsMsgCopyService::DoNextCopy() mailnews/base/src/nsMsgCopyService.cpp 9 XUL nsMsgCopyService::CopyMessages(nsIMsgFolder*, nsIArray*, nsIMsgFolder*, bool, nsIMsgCopyServiceListener*, nsIMsgWindow*, bool) mailnews/base/src/nsMsgCopyService.cpp 10 XUL nsMsgSearchDBView::ProcessRequestsInOneFolder(nsIMsgWindow*) mailnews/base/src/nsMsgSearchDBView.cpp
Blocks: 1136498
Crash Signature: [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr ] → [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr ] [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr]
Summary: crash deleting mail in Unified Folders view? [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)], [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] → crash deleting/moving mail in Unified Folders view? [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr ], [@ nsMsgXFViewThread::RemoveChildHdr] via nsMsgSearchDBView::OnHdrDelete
See Also: → 1344036
Blocks: 1344036
See Also: 1344036
(In reply to Adam Roach [:abr] from comment #14) > bp-af811eb8-357f-4821-bcea-e44e72170413 Adam are you still crashing? I crashed two times in the last day: bp-40a25557-2a37-49f4-9d7f-a46920180323 60.0a1 clicking a merssage in vseerror inbox after deleting a message in wayne.mery@g bp-2e82a8fc-8c19-4b4d-88f3-84d280180323 52.7.0 during compose typing an email This started after creating two new virtual folders both of which watch 60+ folders (even though I already have 10 virtual folders defined, but not actively using). Perhaps related to Bug 775472 - Saved Search virtual folder (collecting mails marked "Unread") doesn't update automatically when incoming new mail is filtered into folders other than inbox - which I've been seeing examples of. Makoto, what do you make of this, or bug 1136498, or bug 1344036?
Flags: needinfo?(m_kato)
Flags: needinfo?(adam)
> Adam are you still crashing? I haven't seen *this* crash in a while now. I have a recent GC/CC crash, but I don't have reason to believe it is related. On the other hand, the telemetry graph does not show that the incidence of this crash is going down at all, so it would appear to be coincidence that I haven't hit it recently, rather than any actual improvement.
Flags: needinfo?(adam)
(In reply to Wayne Mery (:wsmwk) from comment #15) > (In reply to Adam Roach [:abr] from comment #14) > > bp-af811eb8-357f-4821-bcea-e44e72170413 > > Adam are you still crashing? > > > I crashed two times in the last day: > bp-40a25557-2a37-49f4-9d7f-a46920180323 60.0a1 clicking a merssage in > vseerror inbox after deleting a message in wayne.mery@g > bp-2e82a8fc-8c19-4b4d-88f3-84d280180323 52.7.0 during compose typing an > email > > This started after creating two new virtual folders both of which watch 60+ > folders (even though I already have 10 virtual folders defined, but not > actively using). Perhaps related to Bug 775472 - Saved Search virtual > folder (collecting mails marked "Unread") doesn't update automatically when > incoming new mail is filtered into folders other than inbox - which I've > been seeing examples of. > > Makoto, what do you make of this, or bug 1136498, or bug 1344036? Bug 1136498 is related issue. But I don't know whether it is same issue. This bug's crash may be that nsMsgSearchDBView (m_view) is already destroyed or invalid. I don't know root cause.
Flags: needinfo?(m_kato)
See Also: → 646901
I don't recall if it was Ben or Geoff I saw recently lamenting the state of xfolder/virtual folder code. Was that in a bug report? It would be nice if we could make gradual progress / any progress so we can chip away at this topcrash area, because ... per https://mzl.la/2C23P2a little has been fixed in the last 6 years, not since Bug 629487 crash [@ nsMsgDBView::RemoveRows] - except for a minor foray in bug 1385573, which doesn't look like it helped and so needs a followup bug. I just crashed bp-34da6ca5-0410-4f0b-9e26-2ec810181005 nsMsgXFViewThread::RemoveChildHdr But I rarely crash, so I don't have testcase It looks like the average user/installation crashes 3 times, based on https://crash-stats.mozilla.com/signature/?signature=nsMsgXFViewThread%3A%3ARemoveChildHdr&date=%3E%3D2018-07-05T13%3A14%3A17.000Z&date=%3C2018-10-05T13%3A14%3A17.000Z#summary
Crash Signature: [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)] [@ nsMsgXFViewThread::RemoveChildHdr ] [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr] → [@ nsMsgXFViewThread::RemoveChildHdr ] [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr]
Flags: needinfo?(geoff)
Flags: needinfo?(benc)
(In reply to Wayne Mery (:wsmwk) from comment #18) > I don't recall if it was Ben or Geoff I saw recently lamenting the state of > xfolder/virtual folder code. Was that in a bug report? I do complain a lot about the state of the code but I really doubt this was me.
Flags: needinfo?(geoff)
(In reply to Wayne Mery (:wsmwk) from comment #18) > I don't recall if it was Ben or Geoff I saw recently lamenting the state of > xfolder/virtual folder code. Was that in a bug report? If it was me, it probably wasn't about virtual folders specifically, more just the accumulated complexity around folders in general. eg: bug 1317117 comment 30 bug 92165 comment 141 Definitely a lot of scope for simplification and refactoring. It'd definitely help robustness, but it's really hard - there are so many legitimate corner cases and trickiness that's easy to overlook, so it's so easy to break things. Just a case of slowly and methodically chipping away and improving things I think. (and it's not a complaint - it's all just the result of a complex app being exposed to real world use for a long period)
Flags: needinfo?(benc)
Keywords: qawantedsteps-wanted
See Also: → 1518645

straight up delete from imap Inbox - message is not part of thread, and a virtual folder is not currently in display (but this Inbox is in some virtual folders)
bp-0d1b5a72-e151-4fa8-a13f-e453d0190507 60.6.1

Summary: crash deleting/moving mail in Unified Folders view? [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr ], [@ nsMsgXFViewThread::RemoveChildHdr] via nsMsgSearchDBView::OnHdrDelete → crash deleting/moving mail in normal folder or Unified Folders view? [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr ], [@ nsMsgXFViewThread::RemoveChildHdr] via nsMsgSearchDBView::OnHdrDelete - m_view is already destroyed or invalid

The following shows a similar problem:

Remove any installations of Thunderbird including the profile folder
Install Thunderbird from download site https://www.thunderbird.net/en-GB/ taking default options - at the time of writing this installs 68.2.2 (32 bit)
Set up initial account - in my case hosted on chimail.uk2.net using IMAP on port 993 and SMTP on port 465
In Settings, specify Tools/Options and select 'Open messages in:An existing message window' and 'Close message window/tab on move or delete'
Add a second account
Select Unified folders from View/Folders/Unified
Select the unified Inbox
Open a mail - this opens in a new message window, as expected
Delete the mail - it closes the window, as expected

** but:

Select View/Sort By/Descending/Threaded and repeat - the window stays open after deleting a message. The mail itself does not need to be threaded to show this.

https://support.mozilla.org/en-US/questions/1272097 (Paul)
Testing another user claiming a bug where window does not close on delete.
Agreed there was a bug, but also managed to get a crash on last test.

Windows 10
Thunderbird 68.2.1
Set Unified view
The following all performed in the 'Unified Inbox'
Set Sort by to include threaded
Set options: Open messages in: 'An existing message window' and 'Close message window/tab on move or delete'

Double click to open any message - not necessarilly a threaded email.
email opens in new window.
Click on 'Delete' button
Window with deleted messages remains open, but note the 'Delete' button has been removed.
Close 'deleted email' window - top right X

Set options: Open messages in: 'An new message window' and 'Close message window/tab on move or delete'
Open email, email opens in new window, click on 'Delete'. Same result as above.
Close 'deleted email' window - top right X

Set options: Open messages in: 'A new tab' and 'Close message window/tab on move or delete'
Open email, email shows in tab. Click on Delete
Thunderbird program closed immediately - crashed.
Crash reporter:
bp-bc481bac-c68c-4828-a422-b32a70191108

Trying to reproduce crash is proving illusive.

Matt, can you reproduce using comment 23?

(No longer a topcrash)

Flags: needinfo?(unicorn.consulting)

Ok I can reproduce until it get to the close the tab. It just closes as expected without a crash. The windows functionality is obviously broken, the button disappears, but the content nor the windows does. I assume the code is hitting the button instead of the window context when the close is executed. But it should have it's own Bug I think. I can't find anything current. But my Bugzilla fu is not good.

Test done with 68.3.1. EN_US 64Bit
One obvious difference is I use ESET anti virus and Anje uses Norton. Or she did.

See Also: → 1607164

bp-16b405bb-0ff5-401c-824b-966120200212
I had just opened a message in a tab, closed 3 search tabs, filtered on Inbox two or three times.
Clicked on non-Inbox folder and crashed.
(no message deletes in these steps)

Paul, can you still reproduce, or have any crashes?

Flags: needinfo?(psh)

I can still reproduce the error with the window staying open; I have never had a crash.
Out of interest, shouldn't this be listed in the Known Problems in the Release Notes for each version as they are released?
Thanks

Flags: needinfo?(psh)

(In reply to Paul Hatton from comment #30)

...
Out of interest, shouldn't this be listed in the Known Problems in the Release Notes for each version as they are released?

If it were an extremely common problem, and the user could take some action to avoid it. Neither is the case here.

(In reply to Adam Roach [:abr] from comment #16)

Adam are you still crashing?

I haven't seen this crash in a while now.

Okay, I'm seeing it again. This time, I had just hit "delete" on a message in a unified folder view. This is on Windows (where my other crashes were on Macs), so it's definitely not platform-specific:

bp-67ea1c3d-f1e8-4647-84cb-702f90201116

Matt can you still reproduce?

Flags: needinfo?(unicorn.consulting)

related to Bug 1318751 - thread lost from view after deleting top message of thread - or any of https://mzl.la/2M8PRTI ? (unfortunately a long list)

(In reply to Adam Roach [:abr] from comment #32)

(In reply to Adam Roach [:abr] from comment #16)

Adam are you still crashing?

I haven't seen this crash in a while now.

Okay, I'm seeing it again. This time, I had just hit "delete" on a message in a unified folder view. This is on Windows (where my other crashes were on Macs), so it's definitely not platform-specific:

bp-67ea1c3d-f1e8-4647-84cb-702f90201116

but that was version 68. Have you had any crashes, of any signature, when using version 78?

Flags: needinfo?(adam)

Still needs reproducible steps.

Flags: needinfo?(unicorn.consulting)
Flags: needinfo?(adam)
See Also: → 92165

Version 78.14.0 and 91.2.1 both rank ~#50.

Adam indicates he's stuck on version 68 because of a couple add-ons.

_tailMerge_d3dcompiler_47.dll | nsMsgXFViewThread::RemoveChildHdr bp-865eba7a-ec88-4d93-981f-bf6560220616
nsMsgMailNewsUrl::Clone bp-46a8fc15-619e-4fe3-a32c-2051b0220617
nsImapUrl::QueryInterface bp-0856c010-be13-48e2-a4ae-741090220614

Crash Signature: [@ nsMsgXFViewThread::RemoveChildHdr ] [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr] → [@ nsMsgXFViewThread::RemoveChildHdr ] [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr] [@ nsImapUrl::QueryInterface ] [@ nsMsgMailNewsUrl::Clone ] [@ _tailMerge_d3dcompiler_47.dll | nsMsgXFViewThread::RemoveChildHdr ] [@ CommonSocketControl::GetSSLVersi…

As for the steps, we got this report:
In a unified view for some IMAP accounts which is threaded and sorted by date (nsMsgXFViewThread, XF = cross folder), delete a message.

TCW, does some combination of comment 23 and comment 41 crash for you?

Flags: needinfo?(thee.chicago.wolf)

So I can't repro using comment 23 since I can't find where "Open messages in: 'An existing message window' and 'Close message window/tab on move or delete" is anymore.

And using the STR in comment 41, TB did not crash for me (using 103.0b6).

Flags: needinfo?(thee.chicago.wolf)

(In reply to Rachel Martin from comment #41)

As for the steps, we got this report:
In a unified view for some IMAP accounts which is threaded and sorted by date (nsMsgXFViewThread, XF = cross folder), delete a message.

Did the report say which TB the were using to repro?

The user was using 91, but 102 crashes as well, likely also later betas, see link in comment #40. A threaded unified view is perhaps not so common. Apparently it crashes a few times a day, so just a few tries won't reproduce the issue.

(In reply to b1 from comment #45)

The user was using 91, but 102 crashes as well, likely also later betas, see link in comment #40. A threaded unified view is perhaps not so common. Apparently it crashes a few times a day, so just a few tries won't reproduce the issue.

Hmm, so I must be doing something wrong in trying to repro the crash.

I still have the problem with 91.11. It indeed happens only sometimes, it's not systematic. I understand it's difficult to troubleshoot when it cannot be reproduced; if I can provide more info, tell me.

Additional note: the problem seems to be more frequent when using shift-del (permanent delete) than using normal delete

Severity: critical → S2

(In reply to sternmarc from comment #48)

Additional note: the problem seems to be more frequent when using shift-del (permanent delete) than using normal delete

stermarc, is this still true for you?

Flags: needinfo?(sternmarc)
Crash Signature: CommonSocketControl::GetSSLVersionUsed] → CommonSocketControl::GetSSLVersionUsed] [@ nsImapUrl::IsUrlType ]

Yes, still true

Flags: needinfo?(sternmarc)

So this should be tested

  • unified view
  • threaded display
  • (IMAP?)

correct?

Correct (with IMAP)

Duplicate of this bug: 1804141

bp-5da79fca-77d4-4dd5-be76-5ef7c0221124 from bug 1804141 is @ nsNSSSocketInfo::GetProviderTlsFlags

Crash Signature: CommonSocketControl::GetSSLVersionUsed] [@ nsImapUrl::IsUrlType ] → CommonSocketControl::GetSSLVersionUsed] [@ nsImapUrl::IsUrlType ] [@ nsNSSSocketInfo::GetProviderTlsFlags]
Crash Signature: CommonSocketControl::GetSSLVersionUsed] [@ nsImapUrl::IsUrlType ] [@ nsNSSSocketInfo::GetProviderTlsFlags] → CommonSocketControl::GetSSLVersionUsed] [@ nsImapUrl::IsUrlType ] [@ nsNSSSocketInfo::GetProviderTlsFlags] [@ nsPresContext::Release ] [@ mozilla::a11y::LocalAccessible::Value ]

I opened a bug that was closed, saying this is a duplicate. It is happening nearly every day to me. Below are a list of crash id's. This one was opened 12 years ago!!!! Doesn't sound like a fix is imminent. Thunderbird is almost unusable due to the frustration of constantly crashing

bp-482798df-c673-4030-a921-510500221203 12/3/2022, 3:18 PM
View
bp-846ff96a-db27-4e38-99b0-ca6030221201 12/1/2022, 10:27 AM
View
bp-42c1b796-a2e4-4135-af97-5ce020221128 11/28/2022, 6:52 PM
View
bp-563e844a-d0f8-499d-b779-775370221125 11/25/2022, 4:21 PM
View
bp-5da79fca-77d4-4dd5-be76-5ef7c0221124 11/24/2022, 11:24 AM
View
bp-6a2a1412-3bd0-47b8-be82-ffc040221122 11/21/2022, 10:19 PM
View
bp-b833b64d-3528-47c7-a6c7-58b920221121 11/21/2022, 4:27 PM
View
bp-3b68a6c3-69af-4fc5-9226-c467b0221117 11/17/2022, 3:38 PM
View
bp-72c1a04b-dbfa-48a9-85ac-62e7a0221113 11/13/2022, 5:18 PM
View
bp-994d7513-65d5-41d0-babe-5d8690221112 11/12/2022, 9:24 AM
View
bp-ab98ed4d-baa7-4132-b63c-e56820221111 11/11/2022, 5:03 PM
View
bp-de39303d-57dd-4fc7-9475-e8d770221028 10/28/2022, 2:28 PM
View
bp-cb996caf-f0d6-409f-a597-596e60221027 10/27/2022, 10:43 AM
View
bp-1ef3b234-a839-4cf1-9005-49d0b0221021 10/21/2022, 10:37 AM
View
bp-afc8f434-27eb-4276-8bf3-167270221020 10/20/2022, 12:53 PM
View
bp-3ddf0d66-f38b-49e8-b24e-32e180221018 10/18/2022, 5:11 PM
View
bp-4d878578-3f24-43ed-b21f-cbb030221017 10/17/2022, 7:58 PM
View
bp-39bc09ea-44c6-4db4-a47e-bf5d30221015 10/15/2022, 9:38 AM
View
bp-0afc69c7-a8cd-46cc-aaaf-8abd00221008 10/8/2022, 2:00 PM
View
bp-431a21ed-c3b2-4e87-b0dd-edb2d0220929 9/29/2022, 7:43 PM
View
bp-4701b3d3-29a6-4a7b-aef3-e1b920220923 9/23/2022, 2:32 PM
View

(In reply to kgbstrat from comment #56)

I opened a bug that was closed, saying this is a duplicate. It is happening nearly every day to me. Below are a list of crash id's. This one was opened 12 years ago!!!! Doesn't sound like a fix is imminent. Thunderbird is almost unusable due to the frustration of constantly crashing

This could be a Windows 11 specific issue or potentially an NVidia issue. GT 730 is quite long in the tooth. Are you by chance running that critical security release update for your NVidia card (https://www.nvidia.com/en-us/drivers/results/196634/)? Your CPU is a Coffee Lake, yes? Your profile is locally stored, yes?

102.6.0 is coming out next week as is the December Win 11 patch Tuesday update. Maybe one or the other will help?

(In reply to Arthur K. (he/him) from comment #43)

So I can't repro using comment 23 since I can't find where "Open messages in: 'An existing message window' and 'Close message window/tab on move or delete" is anymore.

And using the STR in comment 41, TB did not crash for me (using 103.0b6).

So I want to amend this a bit. I found the "Open messages in: 'An existing message window' and 'Close message window/tab on move or delete" settings and tried to repro again using 108.0b3.

Double click to open any message - not necessarilly a threaded email.
email opens in new window.
Click on 'Delete' button
Window with deleted messages remains open, but note the 'Delete' button has been removed.
Close 'deleted email' window - top right X

This did repro somewhat. On the first repro try, the Delete button doesn't disappear but it just greys out after being clicked. Nothing in Error Console. On second try, clicking the Delete button does close the open window. Same after a third repro try. Seems like it semi-repros on the first try only. Oddly, a ctrl-z action does not perform an undo-delete action and move the deleted message back to the Inbox from where it was deleted.

Set options: Open messages in: 'A new tab' and 'Close message window/tab on move or delete'
Open email, email shows in tab. Click on Delete
Thunderbird program closed immediately - crashed.

No crash for me here. The message opened in a tab closes normally. Here, a ctrl-z action does perform an undo-delete action and moves the deleted message back to the Inbox from where it was deleted.

I'm WFH today but on my work PC I have a copy of TB portable 102.5.0. I'll try to repro using that version tomorrow.

(In reply to Arthur K. (he/him) from comment #58)

(In reply to Arthur K. (he/him) from comment #43)

So I can't repro using comment 23 since I can't find where "Open messages in: 'An existing message window' and 'Close message window/tab on move or delete" is anymore.

And using the STR in comment 41, TB did not crash for me (using 103.0b6).

So I want to amend this a bit. I found the "Open messages in: 'An existing message window' and 'Close message window/tab on move or delete" settings and tried to repro again using 108.0b3.

Double click to open any message - not necessarilly a threaded email.
email opens in new window.
Click on 'Delete' button
Window with deleted messages remains open, but note the 'Delete' button has been removed.
Close 'deleted email' window - top right X

This did repro somewhat. On the first repro try, the Delete button doesn't disappear but it just greys out after being clicked. Nothing in Error Console. On second try, clicking the Delete button does close the open window. Same after a third repro try. Seems like it semi-repros on the first try only. Oddly, a ctrl-z action does not perform an undo-delete action and move the deleted message back to the Inbox from where it was deleted.

I tested with TB Portable 102.5.1 and was not able to repro. Also, the ctrl-z action did not perform an undo-delete action as I observed on my home PC with 108.0b3.

Set options: Open messages in: 'A new tab' and 'Close message window/tab on move or delete'
Open email, email shows in tab. Click on Delete
Thunderbird program closed immediately - crashed.

No crash for me here. The message opened in a tab closes normally. Here, a ctrl-z action does perform an undo-delete action and moves the deleted message back to the Inbox from where it was deleted.

Unable to repro and no crash for me using 102.5.1 as well. A ctrl-z action does perform an undo-delete action here.

Nothing weird in Error Console either.

Does it repro in Safe Mode?

Flags: needinfo?(kgbstrat)

Wonder why this more likely to crash with immediate delete (shift+delete). (I rarely use it)

Also, the version 102 crash rate is rought 2.5x higher than version 91.

https://searchfox.org/comm-central/rev/70eb022d47a9f70631a8db6a3f63575dcf05e21d/mailnews/base/src/nsMsgXFViewThread.cpp#291

bp-ef732c5a-e7e2-41db-b014-c5fbd0230115 windows Crash Address 0xe5e5e5e5e5e5e80d
bp-491db693-949b-435f-8579-14d4e0230114 linux Crash Address 0xe5e5e5e5e5e5e80d
bp-d34897d6-75c4-47b8-9188-9c8460230111 Mac Crash Address 0xe5e5e5e5e5e5e80d

m_view->NoteChange(childIndex + 1, i - childIndex + 1, is noted in comment 7.

Crash Signature: CommonSocketControl::GetSSLVersionUsed] [@ nsImapUrl::IsUrlType ] [@ nsNSSSocketInfo::GetProviderTlsFlags] [@ nsPresContext::Release ] [@ mozilla::a11y::LocalAccessible::Value ] → CommonSocketControl::GetSSLVersionUsed]
Flags: needinfo?(mkmelin+mozilla)
Summary: crash deleting/moving mail in normal folder or Unified Folders view? [@ @0x0 | nsMsgXFViewThread::RemoveChildHdr ], [@ nsMsgXFViewThread::RemoveChildHdr] via nsMsgSearchDBView::OnHdrDelete - m_view is already destroyed or invalid → crash (shift-del) deleting/moving mail in normal or Unified Folders view? [@ nsMsgXFViewThread::RemoveChildHdr] via nsMsgSearchDBView::OnHdrDelete - m_view is already destroyed or invalid

sternmarc,

You mention this only happens sometimes. What percentage of deletes would you say? One in ten? One in fifty?
Unified folder view ? Or saved search?

kgbstrat seems to be gone. frustrated perhaps.

Flags: needinfo?(kgbstrat) → needinfo?(sternmarc)

Frustrated yes. Happens now with much less frequency. No idea what triggers it. I could delete many emails (one at a time with the delete key) with no issue. Then occasionally, same action will crash Thunderbird. The fact that this thread is 12 years old does not give me much hope. If it starts again more frequently, I'll just give up and switch to Outlook (which I really don't want to do).

(In reply to kgbstrat from comment #64)

Frustrated yes. Happens now with much less frequency. No idea what triggers it. I could delete many emails (one at a time with the delete key) with no issue. Then occasionally, same action will crash Thunderbird. The fact that this thread is 12 years old does not give me much hope. If it starts again more frequently, I'll just give up and switch to Outlook (which I really don't want to do).

Just ensure if it does happen that you submit a crash report. The last one from 3 years ago doesn't give much to go on since it doesn't seem to exist anymore. =\

Flags: needinfo?(mkmelin+mozilla)

(In reply to kgbstrat from comment #64)

Frustrated yes. Happens now with much less frequency. No idea what triggers it. I could delete many emails (one at a time with the delete key) with no issue. Then occasionally, same action will crash Thunderbird. The fact that this thread is 12 years old does not give me much hope. If it starts again more frequently, I'll just give up and switch to Outlook (which I really don't want to do).

There should be a 102.7.2 coming soon but would you kindly retest with 102.8.0 next week? If it crashes again, it'll give us a more current look at what's going on. 12 years is a long time for this to still exist but it's tough to say why it's not happened with greater frequency to a greater TB population to merit more resources being put towards finding the cause and fixing it.

Most recent crash report (v102.6.1 - updating to 102.7.2 now)

bp-f06f3e0b-64c1-44f9-a808-9db0b0230209 2/9/2023, 4:27 PM View

https://crash-stats.mozilla.org/report/index/f06f3e0b-64c1-44f9-a808-9db0b0230209

(In reply to kgbstrat from comment #67)

Most recent crash report (v102.6.1 - updating to 102.7.2 now)

Release notes for 102.7.2 state "Various crash fixes" but no specific details. Thanks for being willing to test.

Still an issue. Crashes multiple times per day. Beyond frustrating.

(In reply to kgbstrat from comment #69)

Still an issue. Crashes multiple times per day. Beyond frustrating.

And this is with 102.11.0, yes? Do you happen to have a link to one of your latest crash reports you can share?

Unified is a hornet's nest. I don't seeing it getting attention in the next few months.
I can only suggest trying beta - might be better, same, or worse.

It crashes so often that I'm really envisonning to switch to another program ...

Flags: needinfo?(sternmarc)

(In reply to sternmarc from comment #73)

It crashes so often that I'm really envisonning to switch to another program ...

Understandable. Not seeing anything in the 102.11.0 relnotes that seems like a fix either. I know 115 is not too far away (July-ish).

(In reply to sternmarc from comment #73)

It crashes so often that I'm really envisonning to switch to another program ...

Understood but that's not helpful to this bug report - it doesn't change the crystal ball or help us move forward.

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

(In reply to sternmarc from comment #73)

It crashes so often that I'm really envisonning to switch to another program ...

Understood but that's not helpful to this bug report - it doesn't change the crystal ball or help us move forward.

I didn't want to be rude, just to to sure everyone understands the order of magnitude of the crashes.
I'm ready to help obviously (test some pre-releases or specific fixes for instance).

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

Unified is a hornet's nest. I don't seeing it getting attention in the next few months.
I can only suggest trying beta - might be better, same, or worse.

This might be a clue. I changed from unified to favorites view and have yet to have it crash when deleting emails. More of a pain to use, but beats constant crashes.

#2 crash for 115.3.1 at ~900/week. ~1000 with bug 1344036.

Flags: needinfo?(vseerror)
Priority: -- → P2

@0x0 | nsMsgSearchDBView::OnHdrDeleted bp-a6eb63df-8b39-4df5-990f-e9ab50231023
nsMsgSearchDBView::OnHdrDeleted bp-34e9be06-90db-47a8-a37f-f2fee0231010

Crash Signature: CommonSocketControl::GetSSLVersionUsed] → CommonSocketControl::GetSSLVersionUsed] [@ @0x0 | nsMsgSearchDBView::OnHdrDeleted ] [@ nsMsgSearchDBView::OnHdrDeleted ]
Flags: needinfo?(vseerror)

kgbstrat, can you still reproduce?

Flags: needinfo?(kgbstrat)
See Also: → 1859470

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

kgbstrat, can you still reproduce?

Stopped using Unified folders last time I posted. Recently upgraded to 115.4.1 (64-bit) and use Unified view, but only delete emails within each individual folder under the Unified view. SuperNova messed up the way I used Favorites, so need to use Unified again to somewhat organize in a way I like. Have had no crashes in quite a while. Just tried deleting emails in the Unified folder and was not able to reproduce. I'll try every so often, but assuming my issue has cleared up.

Flags: needinfo?(kgbstrat)
Attached file Crash popup —
Spoke too soon

(In reply to kgbstrat from comment #82)

Spoke too soon

If you go to Help > Troubleshooting Information > scroll down to Crash Reports > is there a crash report shown there? If yes, can you copy the link and post it here?

Flags: needinfo?(kgbstrat)

(In reply to kgbstrat from comment #84)

(In reply to kgbstrat from comment #82)

Spoke too soon

If you go to Help > Troubleshooting Information > scroll down to Crash Reports > is there a crash report shown there? If yes, can you copy the link and post it here?
https://crash-stats.mozilla.org/report/index/0a5057e4-e2b3-4eb2-86af-f47af0231030

Based on this crash info, I need to ask: Is your profile on your C: drive?

(In reply to Arthur K. (he/him) from comment #85)

(In reply to kgbstrat from comment #84)

(In reply to kgbstrat from comment #82)

Spoke too soon

If you go to Help > Troubleshooting Information > scroll down to Crash Reports > is there a crash report shown there? If yes, can you copy the link and post it here?
https://crash-stats.mozilla.org/report/index/0a5057e4-e2b3-4eb2-86af-f47af0231030

Based on this crash info, I need to ask: Is your profile on your C: drive?

Yes, it is located on the C: Drive

In version 115, the crash rate has doubled. So there is some combination of
a) more people using unified folders,
b) a new outright regression,
c) something other than a) and b) making the previous crash more common.

I'm not sure yet what b or c might be. But perhaps it would help to continue the work begun in Bug 1731177 - Refactor nsMsgLocalMailFolder message copying - and related bugs?

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(benc)
Priority: P2 → P1
Depends on: 1731177

Can anyone more easily reproduce this in version 115? With comment 23? (not comment 25)

Flags: needinfo?(sternmarc)
Flags: needinfo?(kgbstrat)
Flags: needinfo?(anjeyelf)

I was not able to reproduce this with 115.4.3, using the comment 23 instructions. I am using Linux, maybe this is not relevant for my OS.

tested in beta 122.0b1 following same as comment 23
Cannot reproduce crash.
All worked as expected.

Flags: needinfo?(anjeyelf)

Steps to reproduce:

  1. Open a cross-folder view.
  2. Open any message amidst this view in a new window.
  3. Close the three-pane window.
  4. Delete the message in the new window.
  5. Repeat step 4, if still possible.

This is my understanding of the problem:

When a message is displayed in a three-pane window or opened in a separate single window, the database view is cloned. In a cross-folder db view this involves copying the table of threads. Unfortunately the copy in the clone contains references to the thread objects of the original view, each of them including a pointer to the original db view, originating here.

The original db view is closed in step 3. In steps 4 and 5, the cloned view receives a notification about the deleted message, resulting in a notification for the already closed view here.

Aside from this crash, there are various other issues with the shallow copies of the xf view threads. Newly added headers are duplicated in the xf threads in each of the clones, while the multiplied deletions cause other strange effects regarding the threading representation, including the infamous empty mails from 1970. This is also responsible for the wrong unread and total message counts in xf threads.

See Also: → 1834801, 1859639
Assignee: nobody → h.w.forms
Attachment #9370586 - Attachment description: WIP: Bug 646168 - When cloning a cross-folder view, make a deep copy of the threads table. r=#thunderbird-reviewers → Bug 646168 - When cloning a cross-folder view, make a deep copy of the threads/groups table. r=#thunderbird-reviewers
Status: NEW → ASSIGNED
See Also: → 1776920

The suggested patch is supposed to fix bug 1776920, bug 1834801 and bug 1859639 as well.

Flags: needinfo?(sternmarc)
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(kgbstrat)
Flags: needinfo?(benc)
Target Milestone: --- → 123 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/81f34ca42e40
When cloning a cross-folder view, make a deep copy of the threads/groups table. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED

Comment on attachment 9370586 [details]
Bug 646168 - When cloning a cross-folder view, make a deep copy of the threads/groups table. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): Apparently this has been never implemented correctly.
User impact if declined: See comment 91.
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): This backend fix may be a bit more risky, but I think it's worth to test it thoroughly in beta.

Attachment #9370586 - Flags: approval-comm-beta?

Thanks. We'll hold this until next week's beta.

See Also: → 1857880
See Also: → 1836212
See Also: → 1447255
See Also: → 1847126
See Also: → 1684277

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

Thanks. We'll hold this until next week's beta.

We will likely skip next week's beta, which means this will ride the train to beta 123 shipping ~Wednesday Jan 24. If all goes well, this might be in 115.8.something two weeks after that.

We need to check whether these go away:

0	xul.dll	nsRefreshDriver::GetVsyncId()	layout/base/nsRefreshDriver.cpp:3014
1	xul.dll	nsMsgXFViewThread::RemoveChildHdr(nsIMsgDBHdr*, nsIDBChangeAnnouncer*)	mailnews/base/src/nsMsgXFViewThread.cpp:291
2	xul.dll	nsMsgSearchDBView::OnHdrDeleted(nsIMsgDBHdr*, unsigned int, int, nsIDBChangeListener*)	mailnews/base/src/nsMsgSearchDBView.cpp:223
3	xul.dll	nsMsgDatabase::NotifyHdrDeletedAll(nsIMsgDBHdr*, unsigned int, int, nsIDBChangeListener*)	mailnews/db/msgdb/src/nsMsgDatabase.cpp:756
4	xul.dll	nsMsgDatabase::DeleteHeader(nsIMsgDBHdr*, nsIDBChangeListener*, bool, bool)	mailnews/db/msgdb/src/nsMsgDatabase.cpp:1775
5	xul.dll	nsMsgDatabase::DeleteMessages(nsTArray<unsigned int> const&, nsIDBChangeListener*)	mailnews/db/msgdb/src/nsMsgDatabase.cpp:1724
6	xul.dll	nsImapMailFolder::CopyMessagesOffline(nsIMsgFolder*, nsTArray<RefPtr<nsIMsgDBHdr> > const&, bool, nsIMsgWindow*

Reason: EXCEPTION_BREAKPOINT

Top 10 frames of crashing thread:

0  mozglue.dll  MOZ_Crash  mfbt/Assertions.h:264
0  mozglue.dll  mozilla::detail::InvalidArrayIndex_CRASH  mfbt/Assertions.cpp:50
1  xul.dll  nsMsgGroupView::OnHdrDeleted  mailnews/base/src/nsMsgGroupView.cpp:686
2  xul.dll  nsMsgDatabase::NotifyHdrDeletedAll  mailnews/db/msgdb/src/nsMsgDatabase.cpp:756
3  xul.dll  nsMsgDatabase::DeleteHeader  mailnews/db/msgdb/src/nsMsgDatabase.cpp:1775
4  xul.dll  nsMsgDatabase::DeleteMessages  mailnews/db/msgdb/src/nsMsgDatabase.cpp:1724
5  xul.dll  nsImapMailFolder::UpdateImapMailboxInfo  mailnews/imap/src/nsImapMailFolder.cpp:2638
6  xul.dll    mailnews/imap/src/nsSyncRunnableHelpers.cpp:122
7  xul.dll  mozilla::RunnableTask::Run  xpcom/threads/TaskController.cpp:555
8  xul.dll  mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal  xpcom/threads/TaskController.cpp:879
Flags: needinfo?(vseerror)
Flags: needinfo?(vseerror)
Whiteboard: [TM 115.8.1]

Comment on attachment 9370586 [details]
Bug 646168 - When cloning a cross-folder view, make a deep copy of the threads/groups table. r=#thunderbird-reviewers

This will be in next week's beta, after the merge

Attachment #9370586 - Flags: approval-comm-beta?
Whiteboard: [TM 115.8.1] → [TM 115.7.1]

Unfortunately, I just discovered a massive problem with single-folder saved searches grouped by sort. Simply selecting a message causes Thunderbird to crash. The following patch seems to work, but I haven't had much time to test it.

Can we exclude the main patch from merging into beta to have some more time to test this follow-up?

Flags: needinfo?(vseerror)
Flags: needinfo?(mkmelin+mozilla)

I think then it's easiest to back out and re-land later with the other fix.

Flags: needinfo?(mkmelin+mozilla)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/26e671149a11
When cloning a cross-folder view, make a deep copy of the threads/groups table. r=mkmelin
https://hg.mozilla.org/comm-central/rev/98812c2301c8
Follow-up fix for grouped-by-sort single-folder search views. r=mkmelin

Status: REOPENED → RESOLVED
Closed: 11 months ago10 months ago
Resolution: --- → FIXED
See Also: → 1876848
Flags: needinfo?(vseerror)
Whiteboard: [TM 115.7.1] → [TM 115.8.0]
Duplicate of this bug: 1875835
See Also: → 1876854
See Also: → 1867389
See Also: → 1838583

Patch may have had an impact on beta crash rate for nsMsgSearchDBView::OnHdrDeleted.

There may be a slight impact on beta crash rate for nsMsgXFViewThread::RemoveChildHdr. But it is far from gone:

In fact, Windows only beta crash rate, appears to have no change.

This hasn't been uplifted to beta yet.

(In reply to Hartmut Welpmann [:welpy-cw] from comment #107)

This hasn't been uplifted to beta yet.

Thanks. I forgot about the backout. I was going by target milestone.

Flags: needinfo?(vseerror)
Target Milestone: 123 Branch → 124 Branch

We may have a winner - beta 124 so far has no crashes for nsMsgXFViewThread::RemoveChildHdr

And no regression bug reports that I can see. Shall we try uplifting to 115?

Flags: needinfo?(vseerror)
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(h.w.forms)

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

Shall we try uplifting to 115?

Well, I think so!

Flags: needinfo?(h.w.forms)
Attachment #9370586 - Flags: approval-comm-esr115?
Attachment #9375455 - Flags: approval-comm-esr115?

As this is based on code changed in Bug 1866951, that one should be uplifted as well.

Depends on: 1866951
No longer depends on: 1731177
Flags: needinfo?(mkmelin+mozilla)

Comment on attachment 9370586 [details]
Bug 646168 - When cloning a cross-folder view, make a deep copy of the threads/groups table. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr115

Attachment #9370586 - Flags: approval-comm-esr115? → approval-comm-esr115+

Comment on attachment 9375455 [details]
Bug 646168 - Follow-up fix for grouped-by-sort single-folder search views. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr115

Attachment #9375455 - Flags: approval-comm-esr115? → approval-comm-esr115+
Duplicate of this bug: 1876673

Anyone who crashed on beta or release(esr) 115 ...

Should find this fixed in beta 124 and 115.9.0 Windows or 115.9.0 Mac

So far, there are no crash reports from 115.9.0, most notably from the highest crash rate signature nsMsgXFViewThread::RemoveChildHdr.

Regressions: 1889990
Duplicate of this bug: 1859470
See Also: 1859470
Duplicate of this bug: 1878469
Regressions: 1878469
Duplicate of this bug: 1843022

Hartmut, great job killing the ancient crash.

Whiteboard: [TM 115.8.0] → [TM 115.9.0]
Duplicate of this bug: 1344036

Indeed, thanks Hartmut! \o/

Duplicate of this bug: 1867389
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: