91.4+ crash frequently typing in compose window. Usually after typing for some time. Nothing in Drafts. nsXPCWrappedJS::Release | CopyListener::~CopyListener
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
People
(Reporter: vkundakci, Unassigned)
References
Details
(Keywords: crash)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
I can force it to happen but it happens often enough to be very annoying.
Actual results:
Thunderbird crashes while typing in the compose window to send mail. Nothing is saved in Drafts even if the compose window was open for a long time and a lot of input has been typed.
Expected results:
Should not crash and allow me to finish typing my email.
Comment 1•3 years ago
|
||
Please do Help > More troubleshooting info. Then scroll down to crash reports. Click on the crash IDs. Please post the URL(s) for the crash ID(s) here in this bug report. Thanks.
Crash report: https://crash-stats.thunderbird.net/report/bp-142fcf74-d9ff-47b5-bfd4-d5e871220114
I mistakenly said "I can force it to happen but it happens often enough to be very annoying." I actually meant to say "I can't force it"... Next time it happens I will try to remember everything that was happening right before the crash. I believe once it was immediately after going to firefox to check or copy something, then back to the tb compose window, and the next thing is that tb crashed.
A previous crash report from TB 91.4.1: https://crash-stats.thunderbird.net/report/bp-920d3bc7-16bc-49e0-b166-afb6c1220105
Comment 4•3 years ago
|
||
vkundakci, Thanks for the details. What antivirus do you run?
nsXPCWrappedJS::Release | CopyListener::~CopyListener goes back three months, and earlier I'm sure. I'm not clear on which existing bug report it matches to. Perhaps the patch from this will help when it gets into version 91: Bug 1742991 - crash nsXPCWrappedJS::AddRef
[ 00 ] nsXPCWrappedJS::Release()
[ 01 ] CopyListener::~CopyListener()
[ 02 ] mozilla::net::nsHttpActivityDistributor::Release()
[ 03 ] nsImapMailCopyState::~nsImapMailCopyState()
[ 04 ] nsImapMailCopyState::~nsImapMailCopyState()
[ 05 ] mozilla::net::SocketData::Release()
[ 06 ] nsImapUrl::~nsImapUrl()
[ 07 ] ??_EnsImapUrl@@O7EAAPEAXI@Z
[ 08 ] nsMsgMailNewsUrl::Release()
[ 09 ] nsImapProtocol::~nsImapProtocol()
[ 10 ] ??_EnsImapProtocol@@GEA@EAAPEAXI@Z
[ 11 ] nsHashPropertyBag::Release()
[ 12 ] nsThread::ProcessNextEvent(bool,bool *)
[ 13 ] NS_ProcessNextEvent(nsIThread *,bool)
[ 14 ] mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate *)
[ 15 ] MessageLoop::RunHandler()
[ 16 ] MessageLoop::Run()
[ 17 ] nsThread::ThreadFunc(void *)
[ 18 ] _PR_NativeRunThread(void *)
[ 19 ] pr_root(void )
[ 20 ] thread_start<unsigned int (__cdecl)(void *),1>
[ 21 ] 0x7ffdf7b67034
[ 22 ] patched_BaseThreadInitThunk(int,void *,void *)
[ 23 ] 0x7ffdf8382651
[ 24 ] 0x7ffdf5e3b670
Magnus, sancus, What's up with frame 10. And what else can we tell from the stack?
I run ESET. If you suspect my AV is the problem maybe I can tell ESET to leave TB alone. Is there anything you can think of I can do?
Are you asking me to run a patch (which I have never done before) or suggesting that a later TB 91 version may fix this? It is very annoying when it happens (like losing a bunch of edits) but happens only 3-4 times a month... Tough to catch.
Comment 6•3 years ago
|
||
In general, yes, AV programs should be set to leave mail software alone. They tend to overreach and cause problems.
There is not a patch to test - wait for 91.5.1 and 91.6.0.
Comment 7•3 years ago
|
||
Yes possible bug 1742991 fixed it. We'll have to see.
I dunno about the strange frame. Maybe bug 1747879 had this effect?
Thanks. I checked ESET Email client integration: They have settings for: MS Outlook, Outlook Express, Windows Mail, Windows Live Mail. They were checked on. Now they're off--should not matter as they don't have TB listed. I also checked off Enable email protection by client plugins. I left SSL/TLS filtering settings alone.
Comment 9•3 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #7)
Yes possible bug 1742991 fixed it. We'll have to see.
I dunno about the strange frame. Maybe bug 1747879 had this effect?
The crash that Wayne linked was in 91.5.0 and the symbolstore thing was just landed for daily symbol files so I don't think that's possible? I have no idea what it is either, though :/
Maybe https://github.com/mozilla-services/minidump-stackwalk can help?
@rjl Rob, any idea? This [ 10 ] ??_EnsImapProtocol@@GEA@EAAPEAXI@Z
frame is pretty weird...
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Bug 1747879 fixed the symbols, so if the cause is missing/wrong symbols, it could have fixed it.
Reporter | ||
Comment 11•3 years ago
|
||
Just happened again. Started forwarding an old email; deleted some text; after editing for 5-10 minutes, poof, crash. System was stable, not busy, no other visible activity was going on. See crash report:
https://crash-stats.thunderbird.net/report/bp-53c93c01-eb43-4aac-a220-b1ab41220118
Comment 12•3 years ago
|
||
(In reply to vkundakci from comment #11)
Just happened again. Started forwarding an old email; deleted some text; after editing for 5-10 minutes, poof, crash. System was stable, not busy, no other visible activity was going on. See crash report:
https://crash-stats.thunderbird.net/report/bp-53c93c01-eb43-4aac-a220-b1ab41220118
same nsXPCWrappedJS::Release
Was this with AV effectively disabled?
(In reply to Magnus Melin [:mkmelin] from comment #10)
Bug 1747879 fixed the symbols, so if the cause is missing/wrong symbols, it could have fixed it.
last crash still shows ??_EnsImapUrl@@O7EAAPEAXI@Z
Comment 13•3 years ago
|
||
Here is how I run minidump_stackwalk:
~/.mozbuild/minidump_stackwalk/minidump_stackwalk DUMP_FILE --symbols-url https://symbols.mozilla.org/ --human
When I run that crash through minidump_stackwalk, those odd-looking entries are not present.
Side note. Symbols files are so far only fixed in comm-central. We would need to uplift the fixes to m-esr91 and c-esr91. And to clarify what is fixed, it's the reference to the file in Mercrial, so I'm not sure that it would make a difference here.
Reporter | ||
Comment 14•3 years ago
|
||
Wayne,
ESET "Email client integration" was on for: MS Outlook, Outlook Express, Windows Mail, Windows Live Mail. When I turn them of ESET sets the red/unprotected alarms--annoying. I just turned off all but MS Outlook which I do not use, which keeps the red alarms off. I don't think they know how to integrate with TB. So the only thing they do is scan imap/pop traffic which is still on. They should not be involved in any compose activity.
"Enable email protection by client plugins" is turned off. This applies to received, sent, and read email which you can individually select if it was turned on.
Comment 15•3 years ago
|
||
Is there a proxy at work here?
Reporter | ||
Comment 16•3 years ago
|
||
No proxy.
Reporter | ||
Comment 18•3 years ago
|
||
I am running 91.6.0 as of 2022-02-08 and no crash. I think 91.5.1 had been fine, also. Last crash was with 91.5.0 about 3 weeks ago. Thanks.
Comment 19•3 years ago
|
||
Thanks for the update
Description
•