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

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

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

Definitely a regression from bug 461566.

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.

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] 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 on attachment 380643 [details] [diff] [review] v1 And approving so that this can land on the trunk for baking...

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.