139512 - GPF During Installation in Regxpcom during install

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Doug Turner (:dougt)]

from a netscape internal bug, cleaned for your viewing pleasure....

What Jband said:

The source of the problem is in xpti (the typelib loader) - my bad, of course.
xpti needs to use libjar (an xpcom component) in order to read the typelibs from
 zipfiles. But, when xpti *first* starts up libjar is not yet registered, so
xpti can not use it and can not find the typeinfos in the zipfiles (there is a
warning printed to the console). This is OK by itself. 

When xpti starts up for the very first time (called by xpcom init) in a clean
build, it notices that its manfest file (xpti.dat) does not exist. So, xpti
tries to read all the xpt/zip files and writes a new xpti.dat for later use. 

After xpcom init is done, regxpcom does an autoreg call which tries to autoreg:
the native (dll) loader, xpti, and the JS loader (in that order). So, by the
time that xpti's autoreg is called it should be able to use libjar since the
component has now been registered. So, the normal case should be that by the
time the JS component loader needs typeinfos from the zip they should be findable.

The problem that we hit is that xpti's autoregister logic does not detect any
changes to the xpt/zip files since its first run (what is stored in xpti.dat).
So, xpti does not bother to try to load the zip contents. This means that when
xpconnect tries to get the interfaceinfo it needs, xpti won't be able to find
it. This cascades into a crash in the security manager (who ASSUMES that a
particular service which happens to require xpconnect can not fail to found).

If you look in xpti.dat after one of these crashes I believe you will find
listings for the .xpt and .zip files. But the only interface infos listed will
be those that came from the .xpt file(s).

The fix for this problem is quite simple. When xpti discovers that it is unable
to get the service it needs from libjar in order to read typelibs from zipfiles
it should *not* record an entry for the zipfile it was trying to read from in
xpti.dat. This means that later when xpti autoreg happens, xpti will 'discover'
that there are zip files in the directory about which it has no information. So,
xpti will read in those zipfiles rather than ASSUMING that it had already
successfully read them (when, in fact, it had not).

Comment 1

[Doug Turner (:dougt)]

Attachment: JBand's Proposed Fix

Comment 2

[Doug Turner (:dougt)]

Adding the right keywords based on bugscape bug 14084.  (Am I suppose to do this?)

Comment 3

[Michael Dunn]

Jaime, please add KWs as appropriate.
Bugscape Bug:
http://bugscape.netscape.com/show_bug.cgi?id=14084

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 80607 [details] [diff] [review]
JBand's Proposed Fix

sr=shaver.  Thanks for the _excellent_ explanation of the problem, jband.

Comment 5

[Doug Turner (:dougt)]

Comment on attachment 80607 [details] [diff] [review]
JBand's Proposed Fix

r=dougt

Comment 6

[Christopher Blizzard (:blizzard)]

Comment on attachment 80607 [details] [diff] [review]
JBand's Proposed Fix

a=blizzard on behalf of drivers for the 1.0 branch

Comment 7

[Doug Turner (:dougt)]

Checked in on branch:
Checking in xptiInterfaceInfoManager.cpp;
/cvsroot/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp,v  <-- 
xptiInterfaceInfoManager.cpp
new revision: 1.33.2.2; previous revision: 1.33.2.1
done

Comment 8

[Doug Turner (:dougt)]

Checking in xptiInterfaceInfoManager.cpp;
/cvsroot/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp,v  <-- 
xptiInterfaceInfoManager.cpp
new revision: 1.34; previous revision: 1.33
done

John, thanks for fixing this so quickly!

Comment 9

[Michael Dunn]

Doug, If checked into the brancjh please set KW fixed1.0.0.
Should an ADTY person "+"?

Comment 10

[scottputterman]

It looks like this already got checked into the branch.  We'd have plussed this.
 Please ask for adt approval in the future before checking into the branch.

Comment 11

[Asa Dotzler [:asa]]

adding fixed1.0.0 keyword (branch resolution). This bug has comments saying it
was fixed on the 1.0 branch and a bonsai checkin comment that agrees. To verify
the bug has been fixed on the 1.0 branch please replace the fixed1.0.0 keyword
with verified1.0.0.