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.)
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
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
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 ?
8 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
Not reprocucable with 2.49a1 under Windws 7 either. Which Antivirus package is installed?
(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.
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.
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 :-(
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
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
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!
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
Still crashing - SeaMonkey / trunk / 2.50a1 / 20161209002017 / Windows 10.0.14393 https://crash-stats.mozilla.com/report/index/4efe369f-b050-4ce8-ac57-b0e912161209
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
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
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.
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.
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
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.
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
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, for i starting at 0, is oob.
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, for i starting at 0, is oob. array 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
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?
> 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 . (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.  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
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.