313610 - JS component fastloading caused compreg.dat issues

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Description

[Boris Zbarsky [:bzbarsky]]

After updating my trees to JS component fastloading, various things (eg location.replace) broke.  I tracked this down to various contract ids returning null when you try to createInstance or getService; the location.replace bustage was due to the "@mozilla.org/js/xpc/ContextStackIterator;1" contract returning null, for example.

If I delete compreg.dat things seem to be OK for some contracts thereafter, but I really shouldn't have to mess with compreg.dat like that, at least in debug builds.

I'll upload a compreg.dat that was causing me problems and hold off on clobbering others for the time being, but I need to test other patches in these trees, so I'd appreciate knowing soonish whether it's ok to just delete the compreg.dat files in them.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: The compreg.dat in question

Note that this is from a seamonkey build.  Firefox reregistered a bunch of times on startup and seemed to come out with a semi-reasonable compreg.dat out of it.

Comment 2

[Brian Ryner (not reading)]

Does an XPC.mfasl file get created when this happens?

Comment 3

[Brian Ryner (not reading)]

Also, if you could run with NSPR_LOG_MODULES=JSComponentLoader:5 (it's enabled for release builds), that would be quite helpful.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Does an XPC.mfasl file get created when this happens?

Not that I can see...

> Also, if you could run with NSPR_LOG_MODULES=JSComponentLoader:5 

I tried that, and the problem did not appear.  :(  I then tried the builds that I hadn't run yet.  Even copying the known-bad compreg file into the components dir doesn't let me reproduce at this point... <sigh>.  Last night and this morning it was quite reproducible.  :(

I guess this is invalid unless I manage to reproduce this again somehow... :(

Comment 5

[Brian Ryner (not reading)]

I can reproduce it by copying the compreg.dat file you attached into the components directory.  However, on closer inspection, this compreg.dat doesn't contain any entry for ContextStackIterator, so it's not surprising that creating it fails.  Even more odd, it does contain entries for most (all?) of the rest of the components registered by libxpconnect.

So the question is, how was this compreg generated?

Comment 6

[Boris Zbarsky [:bzbarsky]]

I had a build pulled at MOZ_CO_DATE="Wed Oct 19 00:30:35 CDT 2005".  This had a compreg.dat that came from whatever registration it had done up to now (it's a dep debug build).

Then I pulled by date for MOZ_CO_DATE="Fri Oct 21 19:49:09 CDT 2005" and compiled.  Then I started the browser.  The attached compreg.dat is what was there when I quit the browser.