Closed Bug 1316416 Opened 8 years ago Closed 8 years ago

Crash in js::SavedStacks::insertFrames 51.0a2

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
Unspecified
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(thunderbird50 unaffected, thunderbird_esr52 affected, thunderbird51 affected, thunderbird52 affected, thunderbird53 affected, thunderbird54 affected, thunderbird55 affected)

Status:
RESOLVED DUPLICATE of bug 1158578
Tracking Flags:
Tracking Status
thunderbird50 --- unaffected
thunderbird_esr52 --- affected
thunderbird51 --- affected
thunderbird52 --- affected
thunderbird53 --- affected
thunderbird54 --- affected
thunderbird55 --- affected

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: crash, topcrash-thunderbird, Whiteboard: [regression:TB51])

Crash Data

Component: Help Documentation → General
Flags: needinfo?(vseerror)
Crashes in JS code. Maybe add-on related? Maybe some add-on is using cache(1)? I spotted LookOut (https://addons.mozilla.org/en-US/thunderbird/addon/lookout/) being used in two cases. Apparently that has problems, so I switched to LookOut+ (https://addons.mozilla.org/en-US/seamonkey/addon/lookout-1/) Also I see CC3C233D-6668-41bc-AAEB-F3A1D1D594F5 0.8.7 used twice, that's Mail Redirect (https://addons.mozilla.org/en-US/thunderbird/addon/mailredirect/)
Flags: needinfo?(o.e.ekker)
Hi, i removed LookOut and MailRedirect. First was only because of one winmail.dat installed and very new. Later was already long installed and never caused problem. Now without both the crash still happen. I submited an new report when the crash hapend while both plugins where removed. It only crash if i try to compact the second imap account.
your last crash with those addons removed is the same signature - bp-90681165-0953-4a29-8c20-815842161113 js::SavedStacks::insertFrames
Mail Redirect isn't using cache, but according to comment #3 it wasn't causing the crash either. I've been using TB51.0a2 for a while now with Mail Redirect 0.8.8ax and never had any crashes (except when typing this msg my windows crashed :-( )
Flags: needinfo?(o.e.ekker)
I deleted the imap store and reload it from the server. After that the compact worked for few times. Now the same error again.
With Version "52.0a2 (2016-11-15) (32-bit)" it is stable again :-)
(In reply to lussnig from comment #7) > With Version "52.0a2 (2016-11-15) (32-bit)" it is stable again :-) Thanks for the update. If you see it again with same or newer Thunderbird please reopen the bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(vseerror)
Resolution: --- → WORKSFORME
Still seeing lots of crashes. bp-9ec980db-6de3-46cd-a9eb-24c142161205 yours from yesterday. What's going on with your system? But it's not just you. #2 crash for 52.0a2 #6 crash for 53.0a1
Flags: needinfo?(vseerror)
Flags: needinfo?(vseerror)
The same problem as before. When i click "Compress" on the first IMAP folder thunderbird remove the deleted mails as expected. Doing the same on the second IMAP folder crashes thunderbird without removing the old mails. As explained both tasks where possible with version "52.0a2 (2016-11-15) (32-bit)". Now i updated to "52.0a2 (2016-12-06) (32-bit)" and it still crashes. 1) Where can i try 53.0a1 ? I thought "Earlybird" is already the newest development release. 2) Is there an 64bit Windows version ? Are there any more information i can provide ?
Is there any way to find out what "Crashes in JS code." JS-Code is relevant for the crash ?
Versions: - 52.0a2 (2016-12-14) (32-bit) - 52.0a2 (2016-12-15) (32-bit) - 52.0a2 (2016-12-16) (32-bit) are working fine without crash. Any information what caused the problem ?
(In reply to lussnig from comment #12) > Versions: > - 52.0a2 (2016-12-14) (32-bit) > - 52.0a2 (2016-12-15) (32-bit) > - 52.0a2 (2016-12-16) (32-bit) > are working fine without crash. Any information what caused the problem ? There are certainly crashes from 12-15 builds [1]. But even if there were not, the crash rate on aurora and nightly [2] is much too low to deduce from a short date range that an an issue is gone. Perhaps more interesting is your other crash signature [3] nsOfflineStoreCompactState::CopyNextMessage, which first appears for 51.0a1 20160917030425 in bp-cb9472ad-be1a-406a-bf0e-a2ef22161003 [1] aurora - https://crash-stats.mozilla.com/signature/?release_channel=aurora&signature=js%3A%3ASavedStacks%3A%3AinsertFrames&date=%3E%3D2016-12-02T15%3A54%3A16.000Z&date=%3C2016-12-16T15%3A54%3A16.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-build_id&_sort=-date&page=1 [2] nightly - https://crash-stats.mozilla.com/signature/?release_channel=nightly&signature=js%3A%3ASavedStacks%3A%3AinsertFrames&date=%3E%3D2016-12-02T15%3A54%3A16.000Z&date=%3C2016-12-16T15%3A54%3A16.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#reports [3] https://crash-stats.mozilla.com/signature/?product=Thunderbird&signature=nsOfflineStoreCompactState%3A%3ACopyNextMessage&date=%3E%3D2016-08-01T16%3A05%3A00.000Z&date=%3C2016-12-16T16%3A05%3A00.000Z&_columns=date&_columns=version&_columns=build_id&_columns=platform&_columns=address&_columns=user_comments&_sort=-date&page=1
I see lussnig is still crashing. bp-7174fbff-e970-4a49-a014-9815e2170108 52.0a2 20170105004021 earliest build currently on crash-stats bp-0ffc7994-5437-403b-9c61-aa7e62160729 2016-07-29 00:42:06 45.2.0 20160630070546
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
52.0a2 (2017-01-12) (32-Bit) does not crash. Since the crash happens with the affected versions always if i do the mailbox compression i would say the last 2 weeks are more stable than the versions before. So if you need more information please tell me what i could do.
fallen to rank #15, so demoting
status-thunderbird52: --- → affected
status-thunderbird53: --- → affected
Keywords: topcrash-thunderbird
mychailo I see you've been getting this crash in 51.0b2 bp-0cfe8f12-b951-4b85-afe0-c16802170119. And then strlen | js::SavedStacks::insertFrames in 52.0b1 bp-dfc9456b-da7e-49ab-b4b4-977542170128 What percentage of startups crash? Thunderbird safe mode does not help? https://support.mozilla.org/en-US/kb/safe-mode-thunderbird And are any addons installed?
Flags: needinfo?(mychailo)
I started the current version in safe mode and it happen again. Installed Extensions: - Lightning AddOns: NONE
(In reply to lussnig from comment #15) > 52.0a2 (2017-01-12) (32-Bit) does not crash. Since the crash happens with > the affected versions always if i do the mailbox compression i would say the > last 2 weeks are more stable than the versions before. > So if you need more information please tell me what i could do. I see your crashes continue. Are you reporting *every* crash? Two of your recent crash signatures are not startup crashes. nsOfflineStoreCompactState::CopyNextMessage (earliest 20160917030425) nsOfflineStoreCompactState::OnStopRequest Today in bp-a164d93f-ae4a-4ae2-acaf-2ab6e2170129 you started in safe mode and again had js::SavedStacks::insertFrames via nsOfflineStoreCompactState::CopyNextMessage and nsMsgMailSession::OnItemPropertyFlagChanged (where it heads into xpcom) Earliest crashes (predating lussing's reports) are 4e23c8a0-5718-4372-80ba-86f6f2160831 2016-08-31 14:46:51 Thunderbird 51.0a1 20160831030441 8f2729cf-f48a-4e9a-970d-1c6c62160827 2016-08-27 17:05:34 Thunderbird 51.0a1 20160823030201 Pushlog from the prior two weeks https://hg.mozilla.org/comm-central/pushloghtml?startdate=2016-08-10+03%3A05%3A00&enddate=2016-08-23+03%3A05%3A00
Flags: needinfo?(lussnig)
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #17) > mychailo I see you've been getting this crash in 51.0b2 > bp-0cfe8f12-b951-4b85-afe0-c16802170119. > And then strlen | js::SavedStacks::insertFrames in 52.0b1 > bp-dfc9456b-da7e-49ab-b4b4-977542170128 > > What percentage of startups crash? > Thunderbird safe mode does not help? > https://support.mozilla.org/en-US/kb/safe-mode-thunderbird > And are any addons installed? It crashes 100% of the time for anything above 50.0b3. No add-ons, and Safe Mode does not prevent it. I was getting an OS X lsd issue that was fairly common for people upgrading to El Cap that I even fixed in hopes of resolving the crash-on-launch. For the Console log, I am seeing the same messages at the moment of crash whether it be v51 or v52: 1/29/17 7:33:04.463 AM thunderbird[4482]: -[__NSDictionaryM UTF8String]: unrecognized selector sent to instance 0x1814cfca0 1/29/17 7:33:04.463 AM thunderbird[4482]: Mozilla has caught an Obj-C exception [NSInvalidArgumentException: -[__NSDictionaryM UTF8String]: unrecognized selector sent to instance 0x1814cfca0]
I may have this figured out. I have another Mac (an MBPR) that I just upgraded from 50.0b3 to 52.0b1, and it initially ran fine without the NSApplication issue in the Console log. Then I installed an updated version of "Theme Font & Size Changer" (TFSC), and after that, it began crashing in the same way as my MacMini. At one time, I had TFSC installed on the MacMini, but I uninstalled it ages ago. I reinstalled TFSC on 50.0b3 on the MacMini to see if there were any non-standard values in its settings, but it was all original, so its not a clear case of TFSC being the cause, but it sure seems like it.
Knowing that it doesn't crash 50.0b3 is useful. And fwiw, your last crash (perhaps the one with TFSC) was js::SavedStacks::getLocation, a different crash signature. bp-81c5609f-1cc7-4e01-9300-0601a2170129#tab-details If you are up for some regression hunting (which would be appreciated) you can install http://mozilla.github.io/mozregression/quickstart.html and the prerequisites for the command line tool. Your starting range is 01-Aug-2016 (the tail end of 50.0a1 development) and 19-Sep-2016 (the tail end of 51.0a1 development)
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #22) > Knowing that it doesn't crash 50.0b3 is useful. And fwiw, your last crash > (perhaps the one with TFSC) was js::SavedStacks::getLocation, a different > crash signature. bp-81c5609f-1cc7-4e01-9300-0601a2170129#tab-details > > If you are up for some regression hunting (which would be appreciated) you > can install http://mozilla.github.io/mozregression/quickstart.html and the > prerequisites for the command line tool. Your starting range is 01-Aug-2016 > (the tail end of 50.0a1 development) and 19-Sep-2016 (the tail end of 51.0a1 > development) I'll have a look at what's required to do a regression analysis.
I manually scanned through the trunk builds and narrowed down the transition from no crash to crash. Let me know if you still want me to run mozregression or scan through a branch. 2016-08-01-03-02-26-comm-central/ no crash 2016-08-10-03-04-48-comm-central/ no crash No installable Mac builds in between. 2016-08-15-03-02-03-comm-central/ crash 2016-08-16-03-05-03-comm-central/ crash 2016-08-18-03-02-02-comm-central/ crash 2016-09-02-03-02-02-comm-central/ crash 2016-10-01-03-04-31-comm-central/ crash 2016-10-19-16-37-03-comm-central/ crash
lussnig, can you try https://archive.mozilla.org/pub/thunderbird/nightly/2016/08/2016-08-14-03-04-23-comm-central/thunderbird-51.0a1.en-US.win32.installer.exe to see if it crashes? (In reply to mychailo from comment #24) >... > 2016-08-10-03-04-48-comm-central/ no crash > No installable Mac builds in between. > 2016-08-15-03-02-03-comm-central/ crash https://hg.mozilla.org/comm-central/pushloghtml?startdate=2016-08-10+03%3A05%3A00&enddate=2016-08-15+03%3A05%3A00
Flags: needinfo?(mychailo)
Whiteboard: [regression:TB51]
51.0a1 (2016-08-14) Works fine 54.0a1 (2017-02-07) Works fine too (after updating)
If you want me to try anything else, let me know.
52.0b2 works.
53.0a2 (2017-02-09) (32-Bit) Works also
Somewhat unclear whether the Mac and Windows crashes have the same origins, and the first observed crash time frames don't seem to completely align. In addition, there are still users crashing with the latest nightly 54.0a1
Flags: needinfo?(lussnig)
Version: 50 Branch → 51 Branch
Currently Nightly and Earlybird works fine for me. 53.0a2 (2017-02-12) (32-Bit) 54.0a1 (2017-02-11) (32-bit)
We might need to address this crasher before releasing. Several comments mention compacting. bp-829cbb8d-d2db-444f-a729-9461b2160916 has a crazy long stack - build 20160913030424 bp-ef9e88ce-17cc-41c1-8cec-b344d2170214 is a shorter example, that does not list any addons the more typical abreviated stack is like bp-05024d72-cb9a-4eb7-8587-1a6b32170211 0 xul.dll js::SavedStacks::insertFrames(JSContext*, js::FrameIter&, JS::MutableHandle<js::SavedFrame*>, mozilla::Variant<JS::AllFrames, JS::MaxFrames, JS::FirstSubsumedFrame>&&) js/src/vm/SavedStacks.cpp:1247 1 xul.dll js::SavedStacks::saveCurrentStack(JSContext*, JS::MutableHandle<js::SavedFrame*>, mozilla::Variant<JS::AllFrames, JS::MaxFrames, JS::FirstSubsumedFrame>&&) js/src/vm/SavedStacks.cpp:1152 2 xul.dll JS::CaptureCurrentStack(JSContext*, JS::MutableHandle<JSObject*>, mozilla::Variant<JS::AllFrames, JS::MaxFrames, JS::FirstSubsumedFrame>&&) js/src/jsapi.cpp:6761 3 xul.dll CaptureStack js/src/jsexn.cpp:244 4 xul.dll js::ErrorToException(JSContext*, JSErrorReport*, JSErrorFormatString const* (*)(void*, unsigned int), void*) js/src/jsexn.cpp:552 5 xul.dll xul.dll@0x1c50f7f 6 xul.dll js::ReportErrorNumberVA(JSContext*, unsigned int, JSErrorFormatString const* (*)(void*, unsigned int), void*, unsigned int, js::ErrorArgumentsType, char*) js/src/jscntxt.cpp:693 7 xul.dll JS_ReportErrorNumberASCII(JSContext*, JSErrorFormatString const* (*)(void*, unsigned int), void*, unsigned int, ...) js/src/jsapi.cpp:5598 8 xul.dll js::ReportOverRecursed(JSContext*) js/src/jscntxt.cpp:272 9 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:364 10 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp:477 11 xul.dll InternalCall js/src/vm/Interpreter.cpp:504 12 xul.dll js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp:523 13 xul.dll MaybeCallMethod js/src/jsobj.cpp:2982 14 xul.dll js::ToPrimitiveSlow(JSContext*, JSType, JS::MutableHandle<JS::Value>) js/src/jsobj.cpp:3087 15 xul.dll js::ToPrimitiveSlow(JSContext*, JSType, JS::MutableHandle<JS::Value>) js/src/jsobj.cpp:3113 16 xul.dll js::ToPrimitiveSlow(JSContext*, JSType, JS::MutableHandle<JS::Value>) js/src/jsobj.cpp:3113 17 xul.dll js::ReportErrorNumberVA(JSContext*, unsigned int, JSErrorFormatString const* (*)(void*, unsigned int), void*, unsigned int, js::ErrorArgumentsType, char*) js/src/jscntxt.cpp:693 18 xul.dll js::ToStringSlow(JSContext*, JS::Handle<JS::Value>) js/src/jsstr.cpp:3047 19 xul.dll js::ToStringSlow(JSContext*, JS::Handle<JS::Value>) js/src/jsstr.cpp:3047 20 xul.dll nsXPCWrappedJSClass::CheckForException(XPCCallContext&, mozilla::dom::AutoEntryScript&, char const*, char const*, nsIException*) js/xpconnect/src/XPCWrappedJSClass.cpp:795 21 xul.dll js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp:523 22 xul.dll nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJSClass.cpp:1237 23 xul.dll nsACString_internal::ReplaceASCII(unsigned int, unsigned int, char const*, unsigned int, mozilla::fallible_t const&) xpcom/string/nsTSubstring.cpp:637 24 xul.dll nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJS.cpp:613 25 xul.dll SharedStub xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:112 26 xul.dll nsMsgSearchTerm::MatchRfc2047String(nsACString_internal const&, char const*, bool, bool*) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/base/search/src/nsMsgSearchTerm.cpp:1081 27 xul.dll nsMsgSearchTerm::MatchRfc822String(nsACString_internal const&, char const*, bool*) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/base/search/src/nsMsgSearchTerm.cpp:1215 28 xul.dll nsAString_internal::Assign(nsAString_internal const&) xpcom/string/nsTSubstring.cpp:420 29 xul.dll nsMsgSearchBoolExpression::OfflineEvaluate(nsIMsgDBHdr*, char const*, nsIMsgSearchScopeTerm*, nsIMsgDatabase*, char const*, unsigned int, bool) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/base/search/src/nsMsgLocalSearch.cpp:146 30 xul.dll nsMsgSearchOfflineMail::MatchTerms(nsIMsgDBHdr*, nsISupportsArray*, char const*, nsIMsgSearchScopeTerm*, nsIMsgDatabase*, char const*, unsigned int, bool, nsMsgSearchBoolExpression**, bool*) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/base/search/src/nsMsgLocalSearch.cpp:691 31 xul.dll nsMsgSearchSession::MatchHdr(nsIMsgDBHdr*, nsIMsgDatabase*, bool*) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/base/search/src/nsMsgSearchSession.cpp:670 32 xul.dll nsMsgDatabase::ContainsKey(unsigned int, bool*) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1865 33 xul.dll nsMsgDatabase::SetKeyFlag(unsigned int, bool, unsigned int, nsIDBChangeListener*) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/db/msgdb/src/nsMsgDatabase.cpp:2600
tracking-thunderbird52: --- → ?
tracking-thunderbird_esr52: --- → ?
Keywords: topcrash-thunderbird
I am more convinced now this really deserves a couple different bugs * Mac-only users crash in 45.x, not clear yet whether they crash in beta * beta crashes all or mostly windows, definitely a regression, occurs in safe mode, may have more than one signature ** David Marks has more than one crash sig mozilla::dom::IsJSAPIActive safe mode bp-410538b4-f5f7-452e-ac7c-381272170204 54.0a1 ** Nick Ashton has more than one crash sig nsScriptSecurityManager::CanCreateWrapper bp-ad108614-02d5-48fb-8e4f-74b7d2170210 52.0b2 *** is the most prolific of all the crashers, but difficult so far to engage. /me really wishes for a comrade in arms for triaging crashes, because I really don't have enough time to track this all down
We can probably get traction focusing on compact. bug 1158578 is highly correlated. magnus says these crashes are reproducible. bp-02192508-a95e-41af-bdaa-c38f22170205 lussnig also gets this crash signature bp-e8587a1b-3eed-4f23-81ab-d4b5f2170213
Depends on: 1158578
I just renewed an old contact. I was hoping to use him as a baseline because he uses nightly and he had tested safe mode. But he killed his crashing today by repairing a couple folders. He was using the xpunge addon as well as manual compact. Quite a variety of signatures - similar to some other users history - and his crashing started in the same time frame cited in previous comments bp-be818833-308e-4f7b-a596-c30722170215 2017-02-15 13:15:29 nsScriptSecurityManager::CanCreateWrapper bp-c1d26bb1-2732-4a11-9b9c-fdef62170214 2017-02-14 14:06:16 js::SavedStacks::insertFrames ... bp-dbf218e7-7193-4840-965a-f8a522170210 2017-02-10 12:35:15 nsContentUtils::SubjectPrincipal ... bp-a01267e9-54a8-4412-942d-e5e922161216 2016-12-16 13:47:43 nsScriptSecurityManager::CanCreateWrapper bp-867a4740-ee1b-4530-b71b-3d72d2161001 2016-10-01 09:20:32 nsCOMPtr_base::~nsCOMPtr_base | nsOfflineStoreCompactState::CopyNextMessage bp-c11230b5-24ec-41cc-8aa7-2b42b2160930 2016-09-30 09:16:20 InvalidArrayIndex_CRASH | nsMsgDBView::GetMsgHdrForViewIndex bp-38b59559-8e59-4e85-90a5-3fd312160928 2016-09-28 15:55:25 nsCOMPtr_base::assign_assuming_AddRef | nsImapMockChannel::Close bp-a16e7a6f-20dd-42a7-9718-b0f632160919 2016-09-19 07:24:04 nsCOMPtr_base::assign_assuming_AddRef | nsImapCacheStreamListener::OnStopRequest bp-6e73ccd7-97d2-460a-a849-351cc2160916 2016-09-16 16:31:34 js::jit::InlineFrameIterator::resetOn bp-829cbb8d-d2db-444f-a729-9461b2160916 2016-09-16 16:31:05 js::SavedStacks::insertFrames bp-290892cb-505c-4b60-aab8-c2e0a2160915 2016-09-15 12:37:02 nsImapService::GetMessageFromUrl bp-9c03b190-9783-4f78-adac-c1dc42160909 20160905030200 51.0a1 2016-09-09 06:20:13 nsCOMPtr_base::~nsCOMPtr_base | nsOfflineStoreCompactState::CopyNextMessage
Maybe an bug in the synchronization of different threads accessing the mailbox database? So that the compress delete entries that are still accessed? That would explain the different locations of the crash.
Very reproducible case described in bug 1343488 comment #0: STR: Attach a BMO message which has CTE quoted-printable to a message and send. Result 1: message/rfc822 attachment looks good in the preview pane. Compose a new message and drag the message/rfc822 attachment to the attachment bucket. Double click the attachment in the attachment bucket - Crash! https://crash-stats.mozilla.com/report/index/bp-e49fbf9b-7fc3-4024-8fa7-243512170301 https://crash-stats.mozilla.com/report/index/bp-aa5a6b84-2661-47b8-8365-efd0c2170301 Using TB 45.x, double clicking the attachment in the attachment bucket is just ignored. If you look at the crash, there seems to be an endless loop of these four calls: 52 xul.dll nsStreamConverter::OnStopRequest(nsIRequest*, nsISupports*, nsresult) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/mime/src/nsStreamConverter.cpp:1081 53 xul.dll nsDocumentOpenInfo::OnStopRequest(nsIRequest*, nsISupports*, nsresult) uriloader/base/nsURILoader.cpp:340 54 xul.dll nsUnknownDecoder::OnStopRequest(nsIRequest*, nsISupports*, nsresult) netwerk/streamconv/converters/nsUnknownDecoder.cpp:301 55 xul.dll nsDocumentOpenInfo::OnStopRequest(nsIRequest*, nsISupports*, nsresult) uriloader/base/nsURILoader.cpp:340
BTW, that it crashed in JS means nothing IMHO, the program is dead before it gets there. At least in the crash I described in comment #37, it's simply overflowing the stack (due to what appears to be an endless loop) well before it gets to the JS code. Tooru-san, can you confirm this. So I'm afraid this crash signature will collect many different problems which at the end all crash at the same location.
Flags: needinfo?(arai.unmht)
the crash signature itself won't have nothing to do with the actual underlying issue that causes over recursion. but hitting stack overflow while reporting the error isn't a good situation... we already know that the stack hits internal limit, and creating saved stack object for it will surely consumes too much memory.
Flags: needinfo?(arai.unmht)
(In reply to Tooru Fujisawa [:arai] from comment #39) > the crash signature itself won't have nothing to do with the actual s/won't/should/
Depends on: 1343536
> So I'm afraid this crash signature will collect many different problems which at the end all crash at the same location. Is there a way we can crash sooner to hopefully make the "diffferent" problems have distinct signatures. Also, perhaps js::jit::InlineFrameIterator::resetOn is related, which mostly cite "compact". https://crash-stats.mozilla.com/signature/?product=Thunderbird&signature=js%3A%3Ajit%3A%3AInlineFrameIterator%3A%3AresetOn&date=%3E%3D2017-03-27T11%3A01%3A59.000Z&date=%3C2017-03-30T11%3A01%3A59.000Z&_columns=date&_columns=version&_columns=build_id&_columns=address&_columns=install_time&_columns=email&_columns=user_comments&_sort=-date&page=1 lussnig is hitting this in nightlies bp-e2e28d99-6906-488f-84dc-5d1652170306, and of course crashing a lot in general. Perhaps we could make better use of him with some guinea pig tests. I'm pretty worried about this one because if its topcrash status on all channels, and if we don't have a patch in mind and tested when 52.0 goes live it could be bad news if it goes rogue. Do you have an idea for a patch?
Flags: needinfo?(jorgk)
Flags: needinfo?(arai.unmht)
See Also: → 1343488
FWIW, lussnig's most recent crashes xpc::AllowContentXBLScope bp-82472904-7ef0-43d4-a42b-44aab2170328 nsImapMockChannel::Close bp-6c3865ab-0ad0-42c8-9603-926f32170326 js::jit::InlineFrameIterator::resetOn bp-2d8b1c73-8a3a-420c-bd01-1a1272170322
(In reply to Tooru Fujisawa [:arai] (almost away until April) from comment #39) > the crash signature itself won't have nothing to do with the actual > underlying issue that causes over recursion. Indeed. There might be a variety of causes, one I singled out in bug 1343536. If we can identity STR for another cause, say IMAP folder compaction, we can look into it further. I use compaction a lot and I have never crashed. I can't do anything with a "mixed bag" and therefore also I don't have any good idea. I think it's a "top crash" since somehow many causes get thrown into the one bucket with no way to discern them. We need reproducible casess, so someone to step forward to say: I do this and it crashes. That said, perhaps Arai has an idea on making the error recovery or reporting better, see comment #39: > hitting stack overflow while reporting the error isn't a good situation (In reply to Wayne Mery (:wsmwk, NI for questions) from comment #41) > lussnig is hitting this in nightlies > bp-e2e28d99-6906-488f-84dc-5d1652170306, and of course crashing a lot in > general. Perhaps we could make better use of him with some guinea pig tests. I'm not sure what make of that, "crashing a lot in general".
Flags: needinfo?(jorgk)
See Also: 1343488 →
I already explained that i can reproduce it nearly with 100% failure raid. I have two imap accounts, the first is able to compact. Nearly always if i try to compact the folder nightly crashes. And i am also open for some testing. I can run windows 32 or 64 bit versions.
So what are you compacting? The inbox? That works on one account and not the other? Is there a chance for a reproducible case? Like take a copy of the folder and MSF file before you compact, then if it failed, restore the copy and try again.
Yes compacting the inbox folder. I can do an copy or simply delete an testmail. Really interesting is that on about 8 out of 10 versions it crashes only on the second account. 1 out of 10 versions crashes on both versions and only on few days 1 out of 10 it workes on both accounts. And there was never the case that the second inbox worked and the first crashes. I currently make an ZIP archive of the Profile folder so it is safe to reproduce.
Personal i wold say that the crash is causedi in these part here is done an modification on the mailbox. And my gues either an race condition with an second thread. Or and Problem with the mailbox size. But this would not explain why it sometimes work. 24 xul.dll nsMsgMailSession::OnItemPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/base/src/nsMsgMailSession.cpp:147 25 xul.dll nsMsgDBFolder::NotifyPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/base/util/nsMsgDBFolder.cpp:4989 26 xul.dll nsMsgDBFolder::SendFlagNotifications(nsIMsgDBHdr*, unsigned int, unsigned int) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/base/util/nsMsgDBFolder.cpp:708 27 xul.dll nsMsgDBFolder::OnHdrFlagsChanged(nsIMsgDBHdr*, unsigned int, unsigned int, nsIDBChangeListener*) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/base/util/nsMsgDBFolder.cpp:1013 28 xul.dll nsMsgDatabase::NotifyHdrChangeAll(nsIMsgDBHdr*, unsigned int, unsigned int, nsIDBChangeListener*) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/db/msgdb/src/nsMsgDatabase.cpp:889 29 xul.dll nsMsgDatabase::SetKeyFlag(unsigned int, bool, unsigned int, nsIDBChangeListener*) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/db/msgdb/src/nsMsgDatabase.cpp:2601 30 xul.dll nsMsgDatabase::MarkOffline(unsigned int, bool, nsIDBChangeListener*) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/db/msgdb/src/nsMsgDatabase.cpp:2386 31 xul.dll nsMsgDBFolder::GetOfflineFileStream(unsigned int, __int64*, unsigned int*, nsIInputStream**) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/base/util/nsMsgDBFolder.cpp:827 32 xul.dll nsImapMailFolder::GetOfflineFileStream(unsigned int, __int64*, unsigned int*, nsIInputStream**) C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/imap/src/nsImapMailFolder.cpp:9780 33 xul.dll nsImapMockChannel::ReadFromLocalCache() C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/imap/src/nsImapProtocol.cpp:9524
Is there a period of time 1, 2 or 3 years ago where you never crashed, or crash far less?
The crashes started less than one year ago. Here is an list from versions that worked fine. There are also some versions in between. And right now after some crashes the last days the version from today "55.0a1 (2017-03-29) (64-bit)" also works fine. 51.0a1 (2016-08-14) 54.0a1 (2017-02-07) 53.0a2 (2017-02-09) (32-Bit) 53.0a2 (2017-02-12) (32-Bit) 54.0a1 (2017-02-11) (32-bit) 55.0a1 (2017-03-29) (64-bit)
The compact crash should be bug 1158578. It's very common for me, happens mostly on my mozilla folder which is fairly big. I suspect size/timing makes it more common, and also I suspect it's related to the new cache backend we started using.
I don't use IMAP much and mainly compact local folders. So, Magnus, if you can reproduce it, you're the perfect candidate to fix it ;-)
See Also: → 1352950
field bug 1352950 for addressing the stack overflow while reporting.
Flags: needinfo?(arai.unmht)
(bug 1343488 is in "see also" not to indicate a causal relationship or shared code, but to facilitate finding it because of other factors)
See Also: → 1343488
Blocks: 1354837
I have 10 IMAP accounts of varying sizes. It only happens on very large accounts (with or without a lot of deleted records) and only started on 52.0 for me. A cache sizing issue is more probable.
If this helps: Adding a COMPACT icon to the toolbar that works for ONE (1) folder crashes instantly Using File -> Compact Folders Will loop through accounts and folders and crash .. eventually and not always. Please let me know if I should continue adding symptoms ...
I believe we must resolve this issue before enabling automatic update to 52.0
status-thunderbird54: --- → affected
status-thunderbird55: --- → affected
status-thunderbird_esr52: --- → affected
tracking-thunderbird52: ? → ---
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
Version: 51 Branch → 51
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #58) > I believe we must resolve this issue before enabling automatic update to 52.0 Which issue exactly are you referring to? We already established that this crash signature collects all sorts of crashes. Two well known ones are covered in bug 1158578, IMAP compact crash, and an esoteric scenario in bug 1343488. Magnus is working on the IMAP compact crash, and I'm all in favour of fixing that. Honza assigned the other bug to himself.
(In reply to Jorg K (GMT+2) from comment #59) > (In reply to Wayne Mery (:wsmwk, NI for questions) from comment #58) > > I believe we must resolve this issue before enabling automatic update to 52.0 > Which issue exactly are you referring to? We already established that this > crash signature collects all sorts of crashes. Not all sorts of crashes when you consider that 90% of crash comments are strictly about compact. and the regressive increase in crashes - which is what this bug was originally about per comment 0. But yes, bug 1158578 has evolved to cover the same territory, so let's kill it. I'm not changing the dynamics here, just raising the stakes because of the crash rate. Track one of them please, I don't care which one.
Let's track bug 1158578 which is explicitly about IMAP compact, which 90% of the comments are about.
tracking-thunderbird_esr52: ? → ---
No longer blocks: 1354837
The biggest cause of the crash signature here has been eliminated in bug 1158578. However, one known cause remains, see bug 1343536.
(In reply to Jorg K (GMT+2) from comment #62) > The biggest cause of the crash signature here has been eliminated in bug > 1158578. However, one known cause remains, see bug 1343536. Right, with ranking dropped from #3 in 52.1.0 to #100+ in 52.1.1, remaining activity should be directed to bug 1343536. To further that, let's dup this bug to bug 1158578
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.