Opening new e-mail compose window crashes [@ InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | nsCommandManager::CommandStatusChanged ] with autocorrect add-on

RESOLVED INCOMPLETE

Status

()

P3
critical
RESOLVED INCOMPLETE
3 years ago
5 months ago

People

(Reporter: aha, Unassigned)

Tracking

({crash, regression})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tbird crash][rare][addon: mms Auto Correct ], crash signature, URL)

(Reporter)

Description

3 years ago
User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48a2
Build identifier: 20161006025928

Reproduction:
1. open new message compose windows with Ctrl+M

Actual:
New window appears and than SeaMonkey crashes.

https://crash-stats.mozilla.com/report/index/7c766d92-2115-49be-b8b3-855732161010

MOZ_CRASH Reason	ElementAt(aIndex = 2, aLength = 2)

InvalidArrayIndex_CRASH(unsigned int, unsigned int)
 -- xpcom/glue/nsTArray.cpp:35
nsTArray_Impl<int, nsTArrayInfallibleAllocator>::ElementAt(unsigned int)
 -- C:/builds/slave/c-a/build/objdir/dist/include/nsTArray.h:1045
nsCommandManager::CommandStatusChanged(char const*)
 -- embedding/components/commandhandler/nsCommandManager.cpp:81
nsComposerCommandsUpdater::UpdateOneCommand(char const*)
 -- editor/composer/nsComposerCommandsUpdater.cpp:329
nsComposerCommandsUpdater::NotifyDocumentCreated()
 -- editor/composer/nsComposerCommandsUpdater.cpp:54
mozilla::EditorBase::NotifyDocumentListeners(mozilla::EditorBase::TDocumentListenerNotification)
 -- editor/libeditor/EditorBase.cpp:2550
mozilla::EditorBase::PostCreate()
 -- editor/libeditor/EditorBase.cpp:308 
...

(Please, move this bug to appropriate component, if I missed it.)

Comment 1

3 years ago
Version due to Crash Report.

NOT reproducible with unofficial en-US SeaMonkey 2.49a1  (NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20160930004545  (Default Classic Theme) on German WIN7 64bit
Status: NEW → UNCONFIRMED
Ever confirmed: false
Version: Trunk → SeaMonkey 2.48 Branch
(Reporter)

Comment 2

3 years ago
Crash with a little bit newer build:
https://crash-stats.mozilla.com/report/index/1e8ce848-b327-41ab-bd9e-949902161010
Release Channel	default / Version: 2.48a2 / Build ID: 20161010025447

Comment 3

3 years ago
NOT reproducible with official en-US SeaMonkey 2.48a2  (NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build 20161010025447  (Default Classic Theme) on German WIN7 64bit:
1. Try <cntrl+m> from Browser - Default page
   No Crash
2. cntrl+m> from Email Client - Start Page (empty Message Pane)
   No Crash

a) WIN10 related?
b) Related to reporter's particular User Profile / Installation /  something else ?
Crash Signature: [@ InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | nsCommandManager::CommandStatusChanged ]
status-seamonkey2.47: --- → unaffected
status-seamonkey2.48: --- → affected
status-seamonkey2.49esr: --- → affected
Hardware: x86_64 → x86
(Reporter)

Comment 4

3 years ago
Crash with a trunk build:
https://crash-stats.mozilla.com/report/index/5b2c0d47-4b3a-48ff-be0e-c84de2161010
Release Channel	default / Version 2.49a1 / Build ID 20161005004944

Rainer, I downloaded ZIP file, unzip it to fresh new directory and run. I created fresh new profile with Classic theme and created fake mail account. SeaMonkey still crashes and the way of opening new e-mail compose window has no effect on result -> SeaMonkey crash after compose window appears. One of several crashes in this setups. Lightning extension is disabled.
https://crash-stats.mozilla.com/report/index/99ea8bc6-2c23-4e5a-9a57-2eef42161010
Release Channel	default / Version 2.49a1 / Build ID 20161005004944
status-seamonkey2.47: unaffected → ---
status-seamonkey2.48: affected → ---
status-seamonkey2.49esr: affected → ---
Hardware: x86 → x86_64
(Reporter)

Updated

3 years ago
status-seamonkey2.47: --- → unaffected
status-seamonkey2.48: --- → affected
status-seamonkey2.49esr: --- → affected
Hardware: x86_64 → x86
Not reprocucable with 2.49a1 under Windws 7 either. 

Which Antivirus package is installed?
(Reporter)

Comment 6

3 years ago
(In reply to Frank-Rainer Grahl from comment #5)
> Which Antivirus package is installed?

Just actual Windows Defender with default settings. When I turned off all these security subsystems, I still crash on the new message compose (also same with all extensions disabled). For the record, I routinely use SeaMonkey/2.44a1 2016020814261 for several months and I have no problems to write e-mails from this version, even now.

Next builds are trunk nightlies.
SeaMonkey/2.47a1 20160731003204 - NO problem, NO crash
SeaMonkey/2.48a1 20160809001736 - NO problem, NO crash
SeaMonkey/2.48a1 20160810001813 - NO problem, NO crash
SeaMonkey/2.48a1 20160817191952 - crash
SeaMonkey/2.48a1 20160818001652 - crash
SeaMonkey/2.48a1 20160902184539 - crash
SeaMonkey/2.48a1 20160912004042 - crash
SeaMonkey/2.49a1 20160923002047 - crash
SeaMonkey/2.49a1 20161001004028 - crash
SeaMonkey/2.49a1 20161005004944 - crash
Regression window is from 10th to 17th August including these dates.
If you could me point to Windows builds inside the window, I will try them.

Aurora builds
SeaMonkey/2.47a2 20160816024401 - NO problem, NO crash
SeaMonkey/2.47a2 20160829030640 - NO problem, NO crash
SeaMonkey/2.47a2 20160903024843 - crash
SeaMonkey/2.47a2 20160904025600 - crash
SeaMonkey/2.47a2 20160907031125 - crash
SeaMonkey/2.47a2 20160914030904 - crash
SeaMonkey/2.48a2 20160924030320 - crash
SeaMonkey/2.48a2 20161010025447 - crash
Regression window is from 29th August to 3rd September including these dates.
(Reporter)

Comment 7

2 years ago
WFM with SeaMonkey/2.49a1 / 20161026000046

Maybe regression from changes by: 
bug 1159244 - Investigate adding non-debug mode bounds checking to nsTArray
(pushed in bug 1159244#c49)

Maybe fixed by:
bug 1312136 - Crash in InvalidArrayIndex_CRASH | nsMsgDBView::GetMsgHdrForViewIndex

Resolving as WFM.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME

Updated

2 years ago
See Also: → bug 1312136
(Reporter)

Comment 8

2 years ago
It's weird, but latest trunk night build crashes same way:
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49a1
Build identifier: 20161107002359
https://crash-stats.mozilla.com/report/index/99ea4f35-3ec6-43e3-985b-d87722161108
https://crash-stats.mozilla.com/report/index/e4c7cc7b-8034-42bf-a94f-a1fc62161108
I'm reopening bug for this reason :-(
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---

Comment 9

2 years ago
NOT REPRODUCIBLE with official DE SeaMonkey 2.49a1  (NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20161107002359  (Default Classic Theme) on German WIN7 64bit
(Reporter)

Comment 10

2 years ago
It seems, that Linux builds are crashing too. Incident is not related to me.
SeaMonkey / aurora / 2.48a2 / 20161010013001 / Linux 3.16.38-64-r1 / amd64
https://crash-stats.mozilla.com/report/index/11fdcbc7-8ddf-4b1a-8e2d-3ff832161103
OS: Windows 10 → All
(Reporter)

Comment 11

2 years ago
alta88: Could you fix also this SeaMonkey crash? It looks similar to bug 1314347, bug 1314348 and bug 1314644 and related to bug 1312136. Thank you for your time!

Comment 12

2 years ago
NOT reproducible with Server-Installation of  unofficial (by FRG) en-US SeaMonkey 2.49a2  (NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20161118170316  (Default Classic Theme) on German WIN7 64bit
(Reporter)

Comment 13

2 years ago
Still crashing - SeaMonkey / trunk / 2.50a1 / 20161209002017 / Windows 10.0.14393
https://crash-stats.mozilla.com/report/index/4efe369f-b050-4ce8-ac57-b0e912161209
status-seamonkey2.50: --- → affected

Comment 14

2 years ago
this is in m-c code, called by editor/ so maybe jorg is interested.  however, it seems very odd that the code in this line is |++i| instead of |i++|
https://hg.mozilla.org/mozilla-central/annotate/a16372ce30b5/embedding/components/commandhandler/src/nsCommandManager.cpp#l100

Comment 16

2 years ago
I have found a work around on linux which is to use the Ice Window Manager (icewm) instead of xfce4-session. The emachine mentioned above was already using icewm which explains the difference. Using icewm means some difference in appearance, i.e. smaller fonts on menus etc.

Comment 17

2 years ago
On de.comm.software.mozilla.misc User "Peter Müller" in "Es geschehen doch noch Wunder: Final SeaMonkey 2.46" (above "Re: Es geschehen doch noch Wunder: Final SeaMonkey 2.46 - Crash bei Strg+M") contribute 2 Crash IDs for WIN10 SM 2.47
bp-697f30a0-a869-4bca-9125-d8c612161204
bp-36d409f5-62ce-4ee0-8289-7d1052161204
Which show completely different Crash Signature, but identical 
MOZ_CRASH Reason:  ElementAt(aIndex = 2, aLength = 2)

What ever that might mean.
(Reporter)

Comment 18

2 years ago
2.49 branch is still crashing, trunk went to non-crashing state sometimes between 13th and 27th December, builds between this two dates are not available on FTP.

Still crashing: SeaMonkey / branch / 2.49a2 / 20161228024918 / Windows 10.0.14393

Crashing:       SeaMonkey / trunk / 2.50a1 / 20161213002544 / Windows 10.0.14393
NOT crashing:   SeaMonkey / trunk / 2.50a1 / 20161227170009 / Windows 10.0.14393
NOT crashing:   SeaMonkey / trunk / 2.50a1 / 20161227214309 / Windows 10.0.14393
NOT crashing:   SeaMonkey / trunk / 2.50a1 / 20161228000046 / Windows 10.0.14393
(Reporter)

Comment 19

2 years ago
2.49 branch builds seem to be WFM for last two days:
Crashing:       SeaMonkey / branch / 2.49a2 / 20161228024918 / Windows 10.0.14393
NOT crashing:   SeaMonkey / branch / 2.49a2 / 20161229025317 / Windows 10.0.14393
NOT crashing:   SeaMonkey / branch / 2.49a2 / 20161230025549 / Windows 10.0.14393

Leaving bug as open for alta88's comment#14 about odd "++i" thing.
Whiteboard: Are there any crashes of builds after 29th December 2016?

Comment 20

2 years ago
Still Crashing for me. Win 8 SeaMonkey 	2.50a1 	20170102004049 
https://crash-stats.mozilla.com/report/index/b4edd60d-a259-4e17-9c19-1d8d12170103
BTW ++i is perfectly valid and even more preferable in for loops than i++.
++i - increases i and returns it.
i++ - increases i but returns value before increase.
In context of for loop return value is irrelevant and ++i makes more efficient code.
I think the problem is connected to situation where observers are removed from commandObservers during iteration. 
Comment "// XXX Should we worry about observers removing themselves from Observe()?" suggests that this can happens

Comment 21

2 years ago
Of course ++i is valid. But where evaluating an out of bounds array index used to not crash, things have been tightened up recently to prevent such sloppiness and now crash.  A number of places in /mailnews have been changed to check array bounds.  So this loop is badly written given the new strictness; it must guarantee to stop a valid upper bound. The hypothesis is that array[1], for i starting at 0, is oob.

Comment 22

2 years ago
I understand that - and in this context ++i or i++ behave same - they indeed guarantee same boundary check. I think that the problem that some observer is removing itself from observers during iteration and basically during the loop commandObservers->Length() changes - however since it is stored in "numItems" prior to entering to loop - we have oob. 
>  The hypothesis is that array[1], for i starting at 0, is oob.
array[1] is oob only in case that array size is 1. However the loop 
for (i = 0; i < 1;  ++i) 
will only iterate for value of i 0. It will exit on i < 1 condition when i is 1.
#41 crash for Thunderbird 52.0
https://crash-stats.mozilla.com/topcrashers/?product=Thunderbird&version=52.0&days=3 claims crash is first seen 2016-08-30 
Earliest Thunderbird crash in previous 6 months found via search is bp-0ab6d480-628c-416c-9d6a-2a5ae2161027

at least one SM user sees other crash signatures, for example
 nsTHashtable<T>::s_HashKey | PLDHashTable::Search | nsClassHashtable<T>::Get | mozilla::net::nsHttpConnectionMgr::SupportsPipelining 
bp-fdf5dec6-d241-4ace-ae62-c12cd2170227

But based on spot checks, most users crashing have no other crash signatures.
And most crashes are Seamonkey
status-seamonkey2.47: unaffected → ---
status-seamonkey2.48: affected → ---
status-seamonkey2.49esr: affected → ---
status-seamonkey2.50: affected → ---
Component: MailNews: Composition → Editor
Keywords: regression
Product: SeaMonkey → Core
Version: SeaMonkey 2.48 Branch → unspecified

Comment 24

2 years ago
I'm on SM Nightly 2.52 - no longer see crashes. I think (but not 100% sure) that SM 2.51 also had not that crash.
No crash by Firefox.  I think that RemoveCommandObserver is called into ""command_status_changed" observer.  Addon?
Priority: -- → P3
> Are there any crashes of builds after 29th December 2016?

yes. But it was pretty quiet for about 2 months. Then with Thunderbird version 52 the crash rate has gone up significantly [1]. (but still rare, ranks ~#200)

I find it quite odd that 95% of crashes are en-US locale. I suspect this is addon related - perhaps autocorrect https://addons.mozilla.org/en-us/thunderbird/addon/mms-auto-correct/
Maybe we should blocklist it.

reporter of https://crash-stats.mozilla.com/report/index/9eda44b0-9a01-4d29-912c-e26a92170405#tab-details wrote that version 45.8.0 does not crash for him. He didn't try safe mode with version 52.

[1] https://crash-stats.mozilla.com/signature/?signature=InvalidArrayIndex_CRASH%20%7C%20nsTArray_Impl%3CT%3E%3A%3AElementAt%20%7C%20nsCommandManager%3A%3ACommandStatusChanged&date=%3E%3D2016-10-20T10%3A22%3A14.000Z&date=%3C2017-04-20T10%3A22%3A14.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#graphs
Whiteboard: Are there any crashes of builds after 29th December 2016? → [tbird crash][rare]
(Reporter)

Comment 27

2 years ago
SeaMonkey 2.48b1 beta release / 20170329183526 / Windows 10 - crash on opening new e-mail message window:
https://crash-stats.mozilla.com/report/index/748edad9-c513-4653-92ba-31b0b0170425
Good news, Everyone! At least for suite it is pretty obvious here:

https://dxr.mozilla.org/comm-central/source/suite/mailnews/compose/MsgComposeCommands.js

Line 1270: commandManager.removeCommandObserver(this, "obs_documentCreated");

The observer is removed while observing it. TB does not remove it in its MsgComposeCommands.js. I wonder why it works on some systems with SeaMonkey. Race condition/timing issue for sure.
I've quality reports of the following:
* caused by MMS Autocorrect add-on (only 800 users, "author" Medvezhonok, which seems to be abandoned) per multiple users, including http://forums.mozillazine.org/viewtopic.php?p=14749166#p14749166 and https://crash-stats.mozilla.com/report/index/9eda44b0-9a01-4d29-912c-e26a92170405#tab-details
* crash happens on the *second* new message window

Comment 30

10 months ago
frg, your opinion remains that unlike bug 1364977 there is nothing we can do here for Thunderbird, and that the crash is caused by the add-on?

By all accounts the add-on still doesn't work* and in some cases causes some crashes, so if there is nothing we can do then it seems we should blocklist it. 

* https://addons.mozilla.org/en-US/thunderbird/addon/mms-auto-correct/reviews/
Flags: needinfo?(frgrahl)
Summary: Opening new e-mail compose window crashes [@ InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | nsCommandManager::CommandStatusChanged ] → Opening new e-mail compose window crashes [@ InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | nsCommandManager::CommandStatusChanged ] with autocorrect add-on
> frg, your opinion remains that unlike bug 1364977 there is nothing we can do here for Thunderbird, and that the crash is caused by the add-on?

It has been a while but yes. The crash occures because the observer is being removed while being observed. This would need changes in mozilla-central and imho not worth it.
Flags: needinfo?(frgrahl)
> the observer is being removed while being observed.

This should have been "the observer is being removed while being notified".
Thanks.  I agree not worth the effort.  So let's call this incomplete.

Related to comment 29, a few days later author shipped a new version ~June 6 per https://addons.thunderbird.net/en-US/thunderbird/addon/mms-auto-correct/

Remains to be seen if there will be an update issued for version 60
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago8 months ago
Resolution: --- → INCOMPLETE
Whiteboard: [tbird crash][rare] → [tbird crash][rare][addon: mms Auto Correct ]
You need to log in before you can comment on or make changes to this bug.