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

REOPENED
Unassigned

Status

()

Core
Editor
P3
critical
REOPENED
11 months ago
3 months ago

People

(Reporter: Adam Hauner, Unassigned)

Tracking

({crash, regression})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tbird crash][rare], crash signature)

(Reporter)

Description

11 months 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

11 months 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

11 months 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

11 months 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

11 months 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

11 months 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

11 months 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

10 months 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: 10 months ago
Resolution: --- → WORKSFORME
See Also: → bug 1312136
(Reporter)

Comment 8

10 months 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

10 months 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

10 months 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

10 months 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

9 months 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

9 months 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

9 months 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 15

9 months ago
This happens to me on Dell Laptop but not on emachine. Both running opensuse linux.

http://crash-stats.mozilla.com/report/index/bp-5cd8afed-2fd5-4b9c-9d2a-db0ec2161209
http://crash-stats.mozilla.com/report/index/bp-814738bf-b06d-4bfa-862d-d04c62161209
http://crash-stats.mozilla.com/report/index/bp-5cd8afed-2fd5-4b9c-9d2a-db0ec2161209

Comment 16

9 months 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

8 months 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

8 months 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

8 months 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

8 months 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

8 months 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

8 months 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

5 months 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?

Updated

5 months ago
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

4 months 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.
Blocks: 1364977
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
You need to log in before you can comment on or make changes to this bug.