Closed Bug 1175190 Opened 10 years ago Closed 10 years ago

Thunderbird 38 crashes in mozilla::mailnews::EncodedHeader [msvcr120.dll | nsCOMArray_base::Adopt | mozilla::mailnews::EncodedHeader]

Categories

(MailNews Core :: Backend, defect)

x86
Windows NT
defect
Not set
critical

Tracking

(thunderbird39 fixed, thunderbird40 fixed, thunderbird41 fixed, thunderbird_esr3839+ fixed, seamonkey2.35+ fixed)

VERIFIED FIXED
Thunderbird 41.0
Tracking Status
thunderbird39 --- fixed
thunderbird40 --- fixed
thunderbird41 --- fixed
thunderbird_esr38 39+ fixed
seamonkey2.35 + fixed

People

(Reporter: wsmwk, Assigned: mkmelin)

References

Details

(Keywords: crash, regression, topcrash-thunderbird)

Crash Data

Attachments

(1 file)

most, but not all, crashes are startup. Because they are startup crashes, many crashes are labeled DUP. Perhaps as high as 75% no stacks sampled match stacks for Fireefox msvcr120 bug reports http://mzl.la/1MIwjdm A high percentage have Calendar installed - but I'm not saying calendar is involved. #6 crash msvcr120.dll@0xf608 | nsTArray_Impl<T>::AppendElements<T>(mozilla::net::PNeckoChild* const*, unsigned int) 1/4 of sample has calendar installed. bp-849664bd-5f48-4f7e-9513-b48e72150613 0 msvcr120.dll msvcr120.dll@0xf608 1 xul.dll nsTArray_Impl<mozilla::net::PNeckoChild*, nsTArrayInfallibleAllocator>::AppendElements<mozilla::net::PNeckoChild*>(mozilla::net::PNeckoChild* const*, unsigned int) 2 xul.dll nsCOMArray_base::Adopt(nsISupports**, unsigned int) 3 xul.dll mozilla::mailnews::EncodedHeader(nsACString_internal const&, char const*) 4 xul.dll nsMsgDBView::FetchAuthor(nsIMsgDBHdr*, nsAString_internal&) 5 xul.dll nsMsgDBView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) 6 xul.dll nsMsgGroupView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) 7 xul.dll nsMsgDBView::GetCellText(int, nsITreeColumn*, nsAString_internal&) 8 xul.dll nsCSSRendering::PaintBorderWithStyleBorder(nsPresContext*, nsRenderingContext&, nsIFrame*, nsRect const&, nsRect const&, nsStyleBorder const&, nsStyleContext*, mozilla::Sides) 9 xul.dll nsCSSRendering::PaintOutline(nsPresContext*, nsRenderingContext&, nsIFrame*, nsRect const&, nsRect const&, nsStyleContext*) 10 xul.dll nsTreeBodyFrame::PaintCell(int, nsTreeColumn*, nsRect const&, nsPresContext*, nsRenderingContext&, nsRect const&, int&, nsPoint) 11 @0xebe0ff no addons bp-0638d29d-bb05-4241-8a93-0fa7f2150614 0 msvcr120.dll msvcr120.dll@0xf608 1 xul.dll nsTArray_Impl<mozilla::net::PNeckoChild*, nsTArrayInfallibleAllocator>::AppendElements<mozilla::net::PNeckoChild*>(mozilla::net::PNeckoChild* const*, unsigned int) 2 xul.dll nsCOMArray_base::Adopt(nsISupports**, unsigned int) 3 xul.dll mozilla::mailnews::EncodedHeader(nsACString_internal const&, char const*) 4 xul.dll nsMsgDBView::FetchAuthor(nsIMsgDBHdr*, nsAString_internal&) 5 xul.dll nsMsgDBView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) 6 xul.dll nsMsgGroupView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) 7 xul.dll nsMsgDBView::GetCellText(int, nsITreeColumn*, nsAString_internal&) #10 crash [@ msvcr120.dll@0xf20c | nsCOMArray_base::Adopt(nsISupports**, unsigned int) ] bp-84abba11-29bf-4024-9322-8947c2150615 0 msvcr120.dll msvcr120.dll@0xf20c 1 xul.dll nsCOMArray_base::Adopt(nsISupports**, unsigned int) 2 xul.dll mozilla::mailnews::EncodedHeader(nsACString_internal const&, char const*) 3 xul.dll nsMsgDBView::FetchAuthor(nsIMsgDBHdr*, nsAString_internal&) 4 xul.dll nsMsgDBView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) 5 xul.dll nsMsgGroupView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) 6 xul.dll nsMsgDBView::GetCellText(int, nsITreeColumn*, nsAString_internal&) #46 crash [@ msvcr120.dll@0xf20c | IPC::ParamTraitsMozilla<T>::Write(IPC::Message*, nsresult const&) ] just one user bp-5ecd6a44-d476-4fe5-8faf-e176a2150614
Is EncodedHeader source of the crash? " I was trying to sort my trash emails by sender. " bp-1aa18ea5-1a11-4648-803e-a2c8f2150616 msvcr120.dll@0xf20c | nsCOMArray_base::Adopt(nsISupports**, unsigned int) 0 msvcr120.dll msvcr120.dll@0xf20c 1 xul.dll nsCOMArray_base::Adopt(nsISupports**, unsigned int) 2 xul.dll mozilla::mailnews::EncodedHeader(nsACString_internal const&, char const*) 3 xul.dll nsMsgDBView::FetchAuthor(nsIMsgDBHdr*, nsAString_internal&) 4 xul.dll nsMsgDBView::GetCollationKey(nsIMsgDBHdr*, int, unsigned char**, unsigned int*, nsIMsgCustomColumnHandler*) 5 xul.dll nsMsgDBView::Sort(int, int) 6 xul.dll nsMsgThreadedDBView::Sort(int, int) Reevaluated startupcrash - by eliminating crashes marked DUP I estimate <10% of crashes are startup. But it's still a top 10 crash after eliminating DUPs
Summary: Thunderbird 38 startup crashes in msvcr120.dll → Thunderbird 38 crashes in mozilla::mailnews::EncodedHeader [msvcr120.dll | nsCOMArray_base::Adopt | mozilla::mailnews::EncodedHeader]
Whiteboard: [startupcrash]
It seems that addresses is null. It mean nsIMsgHeaderParser::ParseEncodeHeader sets null. I think we should check length == 0, then don't call adopt it if 0.
related to bug 1123379 and bug 1023285?
Keywords: regression
See Also: → 1123379, 1023285
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #3) > related to bug 1123379 and bug 1023285? Bug 1123379 is same bug. We should dup of bug 1123379. This is a regression by replacing with JSMIME.
similar to comment 1, the reporter of https://support.mozilla.org/questions/1067789 has crashes prior to bp-5e44a8b8-ae56-4388-a25f-6f90d2150620 about which he writes today I tried accessing the same folder and it worked.. o.O... and then I did another repair and it worked also.. but then I tried to reorder the folder according to the date and it crashed
Component: General → Backend
Product: Thunderbird → MailNews Core
I'd suspect it's likely the case we get an empty string in...
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #8625173 - Flags: review?(Pidgeot18)
Comment on attachment 8625173 [details] [diff] [review] bug1175190_EncodedHeader_crash.patch I'm going to steal this review, since I want this for TB 39b1 LGTM.
Attachment #8625173 - Flags: review?(Pidgeot18)
Attachment #8625173 - Flags: review+
Attachment #8625173 - Flags: approval-comm-esr38?
Attachment #8625173 - Flags: approval-comm-beta?
Attachment #8625173 - Flags: approval-comm-aurora?
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 41.0
Attachment #8625173 - Flags: approval-comm-beta?
Attachment #8625173 - Flags: approval-comm-beta+
Attachment #8625173 - Flags: approval-comm-aurora?
Attachment #8625173 - Flags: approval-comm-aurora+
Do we need confirmation to take this on esr38? I do not have confirm this is gone in nightly or auorora, as the crash rates are too low. (crashes in aurora for the past month look like ~3 users) I am trying to contact one of them, and the users in https://support.mozilla.org/en-US/questions/1068405 https://support.mozilla.org/en-US/questions/1067789
Attachment #8625173 - Flags: approval-comm-esr38? → approval-comm-esr38+
See Also: → 1177702
Depends on: 1177702
I have positive feedback in https://support.mozilla.org/en-US/questions/1067789 that 42.0a1, which has the patch, does not crash
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #12) > I have positive feedback in > https://support.mozilla.org/en-US/questions/1067789 that 42.0a1, which has > the patch, does not crash similar positive results in https://support.mozilla.org/questions/1068405 It's a little early perhaps, but so far no crashes seen for 38.1.0
Status: RESOLVED → VERIFIED
Blocks: 1183275
In THunderbird 38.1.0, this also killed signature OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsTArray_base<T>::EnsureCapacity(unsigned int, unsigned int) | nsTArray_Impl<T>::AppendElements<T>(mozilla::net::PNeckoChild* const*, unsigned int) https://crash-stats.mozilla.com/report/index/bde3b545-be0a-4b1a-a2ce-15db62150728 0 mozalloc.dll mozalloc_abort(char const* const) memory/mozalloc/mozalloc_abort.cpp 1 mozalloc.dll mozalloc_handle_oom(unsigned int) memory/mozalloc/mozalloc_oom.cpp 2 mozalloc.dll moz_xmalloc memory/mozalloc/mozalloc.cpp 3 xul.dll nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) xpcom/glue/nsTArray-inl.h 4 xul.dll nsTArray_Impl<mozilla::net::PNeckoChild*, nsTArrayInfallibleAllocator>::AppendElements<mozilla::net::PNeckoChild*>(mozilla::net::PNeckoChild* const*, unsigned int) xpcom/glue/nsTArray.h 5 xul.dll mozilla::mailnews::EncodedHeader(nsACString_internal const&, char const*) c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/mime/src/MimeHeaderParser.cpp:95 6 xul.dll nsMsgDBView::FetchAuthor(nsIMsgDBHdr*, nsAString_internal&) c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/base/src/nsMsgDBView.cpp:406 7 xul.dll nsMsgDBView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/base/src/nsMsgDBView.cpp:1948 8 xul.dll nsMsgGroupView::CellTextForColumn(int, wchar_t const*, nsAString_internal&) c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/base/src/nsMsgGroupView.cpp:882 9 xul.dll nsMsgDBView::GetCellText(int, nsITreeColumn*, nsAString_internal&) c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/base/src/nsMsgDBView.cpp:1924
Crash Signature: , unsigned int) ] [@ msvcr120.dll@0xf20c | IPC::ParamTraitsMozilla<T>::Write(IPC::Message*, nsresult const&) ] → , unsigned int) ] [@ msvcr120.dll@0xf20c | IPC::ParamTraitsMozilla<T>::Write(IPC::Message*, nsresult const&) ] [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsTArray_base<T>::EnsureCapacity(unsign…
See Also: → 1388723
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: