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

RESOLVED FIXED in mozilla1.9.2a1



10 years ago
8 years ago


(Reporter: paper, Assigned: peterv)


(4 keywords)

1.9.1 Branch
crash, fixed1.9.1, regression, testcase
Bug Flags:
blocking1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)


(crash signature)


(2 attachments)



10 years ago
Created attachment 380538 [details]
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:


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
Regression range:
Ever confirmed: true
Flags: blocking1.9.1?
Keywords: regression
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

10 years ago
Definitely a regression from bug 461566.
Assignee: nobody → peterv
Blocks: 461566

Comment 4

10 years ago
Created attachment 380643 [details] [diff] [review]

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.
Attachment #380643 - Flags: superreview?(jst)
Attachment #380643 - Flags: review?(mrbkap)

Comment 5

10 years ago
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 on attachment 380643 [details] [diff] [review]


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.
Attachment #380643 - Flags: superreview?(jst)
Attachment #380643 - Flags: superreview+
Attachment #380643 - Flags: review?(mrbkap)
Attachment #380643 - Flags: review+
Attachment #380643 - Flags: approval1.9.1?
Attachment #380643 - Flags: approval1.9.1? → approval1.9.1+
Comment on attachment 380643 [details] [diff] [review]

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

Comment 8

10 years ago
Severity: normal → critical
Last Resolved: 10 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
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.
Flags: blocking1.9.1? → blocking1.9.1+


10 years ago
Flags: in-testsuite?
Keywords: fixed1.9.1
Crash Signature: [@ XPCNativeSet::NewInstance(XPCCallContext&, XPCNativeInterface**, unsigned short) ]
You need to log in before you can comment on or make changes to this bug.