952500 - startup crash in nsTArray_Impl<*, nsTArrayInfallibleAllocator>::AppendElements, mainly with Bandoo DataMngr

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Robert Kaiser]

This bug was filed from the Socorro interface and is 
report bp-d7c9e773-1815-4b05-952b-52a152131220.
=============================================================

I have seen the following signatures in top 20 ranks and in top places on the explosiveness reports in the last few days on Firefox 26.0 desktop, on all Windows versions, and >95% within the first minute of startup:

https://crash-stats.mozilla.com/report/list?signature=nsTArray_Impl%3CnsIRequest%2A%2C%20nsTArrayInfallibleAllocator%3E%3A%3AAppendElements%3CnsIRequest%2A%3E%28nsIRequest%2A%20const%2A%2C%20unsigned%20int%29

https://crash-stats.mozilla.com/report/list?signature=nsTArray_Impl%3Cmozilla%3A%3Adom%3A%3Aworkers%3A%3AWorkerRunnable%2A%2C%20nsTArrayInfallibleAllocator%3E%3A%3AAppendElements%3Cmozilla%3A%3Adom%3A%3Aworkers%3A%3AWorkerRunnable%2A%3E%28mozilla%3A%3Adom%3A%3Aworkers%3A%3AWorkerRunnable%2A%20const%2A%2C%20unsigned%20int%29

2013-12-18 data shows the following correlations:

  nsTArray_Impl<nsIRequest*, nsTArrayInfallibleAllocator>::AppendElements<nsIRequest*>(nsIRequest* const*, unsigned int)|EXCEPTION_BREAKPOINT (473 crashes)
    100% (473/473) vs.   4% (1518/40096) DatamngrHlpFF26.dll
    100% (473/473) vs.  19% (7528/40096) wtsapi32.dll
     57% (268/473) vs.   4% (1654/40096) mgrldr.dll
     55% (260/473) vs.   4% (1626/40096) Datamngr.dll
     71% (335/473) vs.  24% (9632/40096) winsta.dll
     40% (187/473) vs.   1% (269/40096) SafetyNutHlpFF26.dll

  nsTArray_Impl<mozilla::dom::workers::WorkerRunnable*, nsTArrayInfallibleAllocator>::AppendElements<mozilla::dom::workers::WorkerRunnable*>(mozilla::dom::workers::WorkerRunnable* const*, unsigned int)|EXCEPTION_BREAKPOINT (179 crashes)
     88% (157/179) vs.   4% (1518/40096) DatamngrHlpFF26.dll
     89% (159/179) vs.  19% (7528/40096) wtsapi32.dll
     62% (111/179) vs.   4% (1654/40096) mgrldr.dll
     61% (109/179) vs.   4% (1626/40096) Datamngr.dll
     73% (130/179) vs.  24% (9632/40096) winsta.dll
     83% (149/179) vs.  56% (22479/40096) ntmarta.dll
     25% (45/179) vs.   1% (269/40096) SafetyNutHlpFF26.dll


I'm not sure if Bandoo (Datamngr.dll, DatamngrHlpFF26.dll, probably SafetyNutHlpFF26.dll, maybe also mgrldr.dll) is causing this or just triggering a problem we have in our code.
I also see there is something with "infallible allocator" at play in both signatures, so I'm not sure if we would have run into an EMPTY signature with this before or if this is new.

Comment 1

[Andrew McCreight [:mccr8]]

It looks like this is happening while the extension is being loaded:
  https://crash-stats.mozilla.com/report/index/b97d8b38-9829-4479-ad02-27fcc2131220

If the stacks are to be believed this is happening when it tries to log an error message kind of thing:
  http://hg.mozilla.org/releases/mozilla-beta/annotate/f8d0c1b35b42/xpcom/components/nsComponentManager.cpp#l500

Comment 2

[Benjamin Smedberg]

The stack is busted. The actual abort is at http://hg.mozilla.org/releases/mozilla-beta/annotate/f8d0c1b35b42/xpcom/components/nsComponentManager.h#l109

This is partly a bug in Firefox which we already fixed in bug 881237, and partly a bug in the extension: the extension is trying to register a component for a CID that already exists, which is against the XPCOM rules. This would fail anyway and report a console message, but because of the bug it's crashing instead.

I don't know why this is showing up with two different signatures, but in any case I think we should block these. The one example in comment 0 doesn't appear to have bandoo, but does have SafetyNutHlpFF26.dll, and a list of extensions that we're already trying to blocklist in bug 949570 with a collection of random IDs.

Jorge/Lukas, do either of you have Bandoo contacts to help us out with the Datamngr stuff and figure out whether SafetyNutHlpFF26.dll is their creation also?

Comment 3

[Benjamin Smedberg]

Oh, interesting datapoint:
SafetyNutHlpFF26.dll 	5.0.0.10654 	EF4C9BF4FCE748BBBB1189CE2E685C121 	DataMngrHlpFF.pdb
DatamngrHlpFF26.dll 	5.0.0.10666 	8388C9D330B74E1DB756EAE34125BB281 	DataMngrHlpFF.pdb

The two DLLs here appear to be almost the same code compiled separately into different filenames. Assuming they use the same CIDs, loading both of them into the same XPCOM process will cause this conflict/crash.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Have reached out to bandoo in email.

Comment 5

[Jorge Villalobos [:jorgev] (he/him)]

Heh, so did I.

Comment 6

[Robert Kaiser]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> This is partly a bug in Firefox which we already fixed in bug 881237

Just to add a data point, that fix is only in Firefox 27, and we're seeing this in 26 here.

Comment 7

[Robert Kaiser]

And I actually suspect that this is the 26 version of what we have seen in 25 as bug 945839

Comment 8

[Robert Kaiser]

It has dropped somewhat but is still around. It's not happening with any version later than 5.0.0.10781 though, as it seems (data from 2014-01-07, Firefox 26.0):

  nsTArray_Impl<mozilla::dom::workers::WorkerRunnable*, nsTArrayInfallibleAllocator>::AppendElements<mozilla::dom::workers::WorkerRunnable*>(mozilla::dom::workers::WorkerRunnable* const*, unsigned int)|EXCEPTION_BREAKPOINT (1561 crashes)
     94% (1471/1561) vs.   4% (4863/115242) DatamngrHlpFF26.dll
          0% (0/1561) vs.   0% (1/115242) 5.0.0.10569
         60% (929/1561) vs.   2% (2423/115242) 5.0.0.10654
          5% (82/1561) vs.   0% (457/115242) 5.0.0.10666
          0% (1/1561) vs.   0% (6/115242) 5.0.0.10687
          5% (82/1561) vs.   0% (243/115242) 5.0.0.10720
          3% (52/1561) vs.   0% (178/115242) 5.0.0.10733
          2% (36/1561) vs.   0% (132/115242) 5.0.0.10741
          4% (56/1561) vs.   0% (127/115242) 5.0.0.10750
         15% (229/1561) vs.   1% (1273/115242) 5.0.0.10781
          0% (1/1561) vs.   0% (2/115242) 5.0.0.10805
          0% (3/1561) vs.   0% (20/115242) 5.0.0.10807
          0% (0/1561) vs.   0% (1/115242) 5.0.0.10906

Comment 9

[BugBot [:suhaib / :marco]]

Closing because no crashes reported for 12 weeks.