495554 - crash [@ XPCNativeSet::NewInstance(XPCCallContext&, XPCNativeInterface**, unsigned short) ]

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[ArronM (:paper)]

Attachment: Javascript XPCom object that crashes FF3.5b4

I was able to reproduce this by creating a Javascript XPCOM Component, using nsICategoryManager.addCategoryEntry with "JavaScript global constructor" to the object it available in javascript.  Initializing the component in Javascript causes this crash.

Here's one of the crashes I generated:
http://crash-stats.mozilla.com/report/index/75982019-576e-4419-a37a-b5d562090529

js/src/xpconnect/src/xpcwrappednativeinfo.cpp:860 


Steps to reproduce:

1) Install attached XPI
2) either navigate to chrome://tuxsmcrash/content/test.html or, in Error Console, evaluate "new TuxSMCrash()"
3) See it crash :)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

This doesn't crash on FF 3.0, 2.x, 1.5.  Does crash on Seamonkey 2.0a3

Comment 1

[Ria Klaassen (not reading all bugmail)]

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2776db2defa2&tochange=f5a48a82dca6

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Peter/jst: can you take a look at this? Seems to be related to changes made by either:

bug 461566 - Don't call FindTearoff when not needed and cache XPCNativeInterfaces in quickstubs

bug 461563 - Allow WrapNative to return a jsval without the wrapper

Comment 3

[Peter Van der Beken [:peterv]]

Definitely a regression from bug 461566.

Comment 4

[Peter Van der Beken [:peterv]]

Attachment: v1

I think we should wait to get an interface as late as possible, because if we have classinfo we don't need it (so only do it if we don't). The automarking pointer isn't completely free, but we shouldn't hit this case that often.

Jst or mrbkap, whoever gets here first should feel free to just r/sr :-).

Not sure how I can test this, needs a custom component.

Also not sure that we should block. I'd take the fix for sure, but I think this might be a rare crash.

Comment 5

[ArronM (:paper)]

I hope the fix is low risk enough to go into the 1.9.1 branch, because I'd hate for my extension to not be compatible with FF 3.5.
  
However, if it can't make it into the branch, can anyone see a way to workaround this crash with respect the attached sample extension?

Comment 6

[Johnny Stenback (:jst)]

Comment on attachment 380643 [details] [diff] [review]
v1

r+sr=jst

Peterv, I do think we should get this in for 1.9.1, but let's start with getting it in to the trunk ASAP for baking.

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 380643 [details] [diff] [review]
v1

And approving so that this can land on the trunk for baking...

Comment 8

[Peter Van der Beken [:peterv]]

http://hg.mozilla.org/mozilla-central/rev/ab395a1916be

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

I think comment 6 implies that this is a blocker, jst, please flip the flag to - and flip wanted 1.9.1.x to + if that wasn't your intent.