xptcall is capped at something like 249 methods. I ran into that today with some DOM interfaces and orange builds.... but that code should just have not compiled instead of dying on pure virtual calls, imo.
I have a patch which: 1. Causes an error with xpidl 2. Prevents the interface from being loaded with xpt (un)Fortunately, nsIDOMCSS2Properties has 469 methods on my machine, so it's a good check to make sure that we actually fail hard in these cases.
Created attachment 551089 [details] [diff] [review] First cut This is a first cut at the bug. bz suggested over IRC that I elide the check in case of builtinclass interfaces. Since the real problem is over whether or not in can be stubbed, I'm also going to track down the stub generation code and make that fail.
http://dxr.mozilla.org/mozilla/mozilla-central/xpcom/reflect/xptcall/src/xptcall.cpp.html#l69 Builtinclasses already fail the stub generation, so there shouldn't be a problem to failing to load that xpt file.
Created attachment 551103 [details] [diff] [review] Patch, version 1 This omits the error in case of builtinclass.
(In reply to Boris Zbarsky (:bz) from comment #0) > xptcall is capped at something like 249 methods. I ran into that today with > some DOM interfaces and orange builds.... but that code should just have not > compiled instead of dying on pure virtual calls, imo. When you say 'xptcall' is capped, you mean the stubs, and not NS_InvokeByIndex, right?
I mean the stubs, yes.
Just a few days, and I can't import this to m-i atm, clearing checkin-needed until patch is updated.
I refreshed the patch and pushed to mozilla-inbound...