1965304 - Crash in [@ nsCopyRequest::~nsCopyRequest]

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Corey Bryant]

#1 bug on 139.0b1
Crash existed before 139 but became more prevalent in 139.0a1.
One user mentioned it occurred when they stopped a send mid-copy.
Another user said they were copying the text of an email when it occurred.

Crash report: https://crash-stats.mozilla.org/report/index/14f812bb-9ef6-42a3-a0c5-a63fd0250508

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  nsCopyRequest::~nsCopyRequest()  mailnews/base/src/nsMsgCopyService.cpp:50
1  xul.dll  nsMsgCopyService::ClearRequest(nsCopyRequest*, nsresult)  mailnews/base/src/nsMsgCopyService.cpp:172
2  xul.dll  nsMsgCopyService::NotifyCompletion(nsISupports*, nsIMsgFolder*, nsresult)  mailnews/base/src/nsMsgCopyService.cpp:569
3  xul.dll  XPTC__InvokebyIndex()  /builds/worker/workspace/obj-build/toolkit/library/build/Z:/builds/worker/checkouts/gecko/xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm:97
4  xul.dll  CallMethodHelper::Invoke()  js/xpconnect/src/XPCWrappedNative.cpp:1620
4  xul.dll  CallMethodHelper::Call()  js/xpconnect/src/XPCWrappedNative.cpp:1174
4  xul.dll  XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)  js/xpconnect/src/XPCWrappedNative.cpp:1120
5  xul.dll  XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)  js/xpconnect/src/XPCWrappedNativeJSOps.cpp:966
6  xul.dll  CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::...  js/src/vm/Interpreter.cpp:494
6  xul.dll  js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstru...  js/src/vm/Interpreter.cpp:590

Comment 1

[Wayne Mery (:wsmwk)]

Earliest nightly build is https://crash-stats.mozilla.org/report/index/2c256847-eece-45dc-b65d-ecbb60250409 Build ID 20250408104447

Comment 2

[Corey Bryant]

The crash rate for beta has been increasing (See "Stability Metrics - Crash Rates"). Currently beta (139) is at 0.32% crash rate and release (138) is at 0.11%. This bug is contributing to that increase. It's hard to tell what else has contributed to the increase but this is the #1 bug.

Here are the top crashers for current 139 beta versions.

Comment 3

[Wayne Mery (:wsmwk)]

https://crash-stats.mozilla.org/report/index/36f6f426-53e6-40a1-b999-400c30250507 "just send a reply to the update email from Corey!!! I stopped the SEND mid copy to folder when TB crshed"

Comment 4

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Attachment: crash on cancel copy.gif

Hello,

I am able to 100% reproduce this crash on Windows 11 and Windows 10 when canceling in the "Copying message to Sent Folder" stage of sending a message on 139.0b3(20250513174533) and 138.0.1(20250512083454). Did not manage to encounter this crash on esr115.18.0(20241211204238) nor esr128.10.1(20250513063440)

The crash signature for one of my crashes (on 139.0b3) should be here (don't have privileges to view user comments).

However I was not able to reproduce this crash neither on macOS 15.4.1, nor Ubuntu 24 with more than 10 attempts each.
It is also worth mentioning that I was unable to reproduce this crash by "copying the text of an email" on any of my devices (win, mac , linux).

Comment 5

[Magnus Melin [:mkmelin]]

Attachment: Bug 1965304 - Fix Crash in [@ nsCopyRequest::~nsCopyRequest]. r=#thunderbird-back-end-reviewers

I suspect nsCopyRequest gets unlinked too early. m_copySourceArray is not null but internally already not usable.
So clear that up first...

Comment 6

[Magnus Melin [:mkmelin]]

Fingers crossed.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7d2abc18892e
Fix Crash in [@ nsCopyRequest::~nsCopyRequest]. r=tobyp

Comment 8

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello,

Using the build from Treeherder from this revision : a296bb59b1ddGLBug 1967628 - Port Bug 1967217: Fix decision task for removed file. rs=bustage-fix I was able to confirm that the crash is no longer present using the STR used in comment 4 on Windows 10 and Windows 11.

Comment 9

[Magnus Melin [:mkmelin]]

Thanks Vlad!

Comment 10

[Magnus Melin [:mkmelin]]

Comment on attachment 9488270 [details]
Bug 1965304 - Fix Crash in [@ nsCopyRequest::~nsCopyRequest]. r=#thunderbird-back-end-reviewers

Uplift Approval Request

• Please state case for uplift consideration and ensure bug severity is set: Crash
• User impact if declined: May crash
• Is this code covered by automated tests?: No
• Has the fix been verified in Daily?: Yes
• Has the fix been verified in Beta?: No
• Needs manual test from QA?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very contained fix
• String changes made/needed: none

Comment 11

[Corey Bryant]

Comment on attachment 9488270 [details]
Bug 1965304 - Fix Crash in [@ nsCopyRequest::~nsCopyRequest]. r=#thunderbird-back-end-reviewers

[Triage Comment]
Approved for release
Approved for esr128

This will be in next week's merge of cc->beta. I'd like to uplift to comm-release and comm-esr128 now for next Tuesday's releases. Considering it's a simple fix and Vlad already tested, I think it is very low risk.

Comment 12

[Corey Bryant]

Thunderbird 128.11.0esr:
https://hg.mozilla.org/releases/comm-esr128/rev/3abba23fa667

Comment 13

[Corey Bryant]

Thunderbird 139.0:
https://hg.mozilla.org/releases/comm-release/rev/6ab3905bedb7

Comment 14

[Wayne Mery (:wsmwk)]

Crash rate (including 139.0) is unchanged per https://crash-stats.mozilla.org/signature/?signature=nsCopyRequest%3A%3A~nsCopyRequest#graphs

• a nightly crash report with build of 05-26 (patch landed 05-20) bp-2e83cf44-cc4d-41f4-a898-92ccd0250527
• version 139.0 crashes

Comment 15

[Hartmut Welpmann [:welpy-cw]]

I just used mozregression with the steps from comment 4: regression window.

Comment 16

[Hartmut Welpmann [:welpy-cw]]

I was still able to reproduce this with 139.0 and the latest self-compiled 141 build. With 139.0 I needed a few tries, maybe it depends on the exact time the save is cancelled. With the patch from bug 1969272 applied, I could not reproduce it yet, but maybe I was just lucky…

Comment 17

[Hartmut Welpmann [:welpy-cw]]

This crash happens because clearRequest is called a second time on the exact same object, after the notifyCompletion call from MessageSend.sys.mjs already triggered this. So bug 1969272 really should fix this as well (and does in my tests).

Comment 18

[Magnus Melin [:mkmelin]]

Alright, well, let's call it fixed. Perhaps there are different angles then. Unclear to me if bug 1969272 fixed the same or different variation.

Comment 19

[Wayne Mery (:wsmwk)]

https://crash-stats.mozilla.org/signature/?signature=nsCopyRequest%3A%3A~nsCopyRequest&date=%3E%3D2025-03-14T02%3A22%3A00.000Z&date=%3C2025-09-14T02%3A22%3A00.000Z shows a few version 142 crashes, otherwise mostly clean for versions 140 and 141.