1123379 - crash in memcpy | nsTArray_Impl<mozilla::dom::PFileSystemRequestChild*, nsTArrayInfallibleAllocator>::AppendElements<mozilla::dom::PFileSystemRequestChild*>(mozilla::dom::PFileSystemRequestChild* const*, unsigned int)

Status: RESOLVED WONTFIX

(MailNews Core :: Database, defect)

Description

[rctgamer3]

This bug was filed from the Socorro interface and is 
report bp-9460ec12-aaed-442a-861f-347932150119.
=============================================================
Thunderbird keeps crashing when I try to sort email by typing a search query into the quick filter.

Might be caused by the "Expression Search" add-on.
https://addons.mozilla.org/addon/1339

Comment 1

[Kent James (:rkent)]

The code in question is this:


85 nsCOMArray<msgIAddressObject> EncodedHeader(const nsACString &aHeader,
86                                             const char *aCharset)
87 {
88   nsCOMPtr<nsIMsgHeaderParser> headerParser(services::GetHeaderParser());
89   msgIAddressObject **addresses;
90   uint32_t length;
91   DebugOnly<nsresult> rv = headerParser->ParseEncodedHeader(aHeader, aCharset,
92     false, &length, &addresses);
93   MOZ_ASSERT(NS_SUCCEEDED(rv), "This should never fail!");
94   nsCOMArray<msgIAddressObject> retval;
95   retval.Adopt(addresses, length);
96   return retval;
97 }

with the crash on retval.Adopt()

My guess is that ParseEncodedHeader failed, leaving garbage values in addresses and length. One possible fix would be to initialize length to 0. But these are wild guesses.

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to rctgamer3 from comment #0)
> Might be caused by the "Expression Search" add-on.
> https://addons.mozilla.org/addon/1339

So it does not crash if the addon is disabled?

Comment 3

[rctgamer3]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> (In reply to rctgamer3 from comment #0)
> > Might be caused by the "Expression Search" add-on.
> > https://addons.mozilla.org/addon/1339
> 
> So it does not crash if the addon is disabled?
It does crash, even with the add-on disabled.

Comment 4

[Wayne Mery (:wsmwk)]

I see no crashes other than 34 beta. https://crash-stats.mozilla.com/report/list?signature=memcpy+|+nsTArray_Impl%3Cmozilla%3A%3Adom%3A%3APFileSystemRequestChild*%2C+nsTArrayInfallibleAllocator%3E%3A%3AAppendElements%3Cmozilla%3A%3Adom%3A%3APFileSystemRequestChild*%3E%28mozilla%3A%3Adom%3A%3APFileSystemRequestChild*+const*%2C+unsigned+int%29&product=Thunderbird&query_type=is_exactly&range_unit=weeks&process_type=any&hang_type=any&date=2015-03-09+19%3A00%3A00&range_value=4#tab-reports

if you cannot reproduce in 36 beta, then I think we can close this.

Comment 5

[rctgamer3]

https://crash-stats.mozilla.com/report/index/7019426d-6ffb-4580-ad96-d229c2150309
https://crash-stats.mozilla.com/report/index/af8e0be5-a559-402e-9c65-32f002150309

Still crashes in 36.0b1. It has a different crash signature, though:
memcpy_s | nsCOMArray_base::Adopt(nsISupports**, unsigned int)

Comment 6

[rsx11m]

The initial crash signature is also observed in current SeaMonkey 2.33.1 release (36.0 equiv):
https://crash-stats.mozilla.com/report/index/0ef229de-59de-4899-9296-9d8c12150602

Quoting from http://forums.mozillazine.org/viewtopic.php?f=40&t=2938787
> SeaMonkey Browser opens and seems to work well.
> SeaMonkey mail opens but if I try to do anything it crashes.

Note that in this case, the originating call before EncodedHeader is
nsMsgDBView::FetchAuthor(nsIMsgDBHdr*, nsAString_internal&)

Thus, it may not depend on a searching operation but general header fetching in the database.

Comment 7

[rsx11m]

Reporter for the occurrence referred to in comment #6 states that he is using a POP account, in case it makes any difference (i.e., local mailbox; quick-filter works locally as well).

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.