178243 - corrupt compreg.dat prevents build from starting

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[John Morrison]

I'm not sure how this happened, but somehow my compreg.dat was corrupted and
the build was just hanging at the splash screen. After poking around a bit,
I tried renaming compreg.dat, and the the build would then start. I'll attach
the good and bad compreg.dat files here.

More detail: I had kicked off a build before I went home last night. This 
evening I came in and started the build OK and used it for three hours and
then shut down. When I went to restart the build it would just hang. The
timestamp on compreg.dat (the bad one) was 18:31. So it looks like the build
did something that required registration to run again, but what was written 
out was bogus. 

It's quite possible that I was out of disk space on that drive (when I started 
trying to figure out what was wrong, disk space was only about 150KB free).
Perhaps we need a little bit of safety checking when writing out the 
compreg.dat file. (On one hand, it's a corner case, but on the other hand, it
completely hosed the build and a naive user will never recover).

Comment 1

[John Morrison]

Oh, by the way ... when it hangs, it also winds up allocating about 50MB of 
heap. In the debugger, I think it was trying to create a new XUL window (for 
the profile manager) again and again and again.

Comment 2

[John Morrison]

Attachment: 'diff -u _bad_compreg.dat _good_compreg.dat'

Maybe a diff is more useful than the original files (although if you want
those, I can attach them as well). Note what appears to be a big chunk of 
missing info at the bottom of the diff.

Comment 3

[Doug Turner (:dougt)]

running out of diskspace would cause a problem like this.  We should add a check
for this condition before trying to create the new compreg.dat.

Do you have any other *.dat files in the components directory?

Comment 4

[John Morrison]

Yes, I have a 'xpti.dat' file in './components', but it's timestamp is from
last Friday (i.e., it hadn't been modified).

Comment 5

[R.K.Aa.]

*** Bug 187872 has been marked as a duplicate of this bug. ***

Comment 6

[Doug Turner (:dougt)]

I am not sure it is worth fixing this in xpcom.  Checking for disk space may
just be an install issue.  Thoughts?

Comment 7

[John Morrison]

Yes, the installer does check for sufficient disk space (although perhaps it 
should pad its estimate to account for the creation of compreg.dat and other 
files on the first run after install). If that is done, then a typical user
would not have a problem. 

But what about third-party xpinstall-ed packages? That would cause autoreg
to run again, no. That could result in a problem if those installers don't 
do the proper check.

But, on the whole, this still seems like an edge case.

Comment 8

[Doug Turner (:dougt)]

most installers, including xpinstall, have ways to check for disk space.  

i am going to future; 

Comment 9

[Jozef Riha]

the same thing happened to me.. :( i am attaching the corrupted compreg.dat too.
hope that helps

cheers and thanks for bug-reporting..

-- jose

Comment 10

[Martin Mokrejs]

Hi,
  so what is the status of this bug? Will mozilla die with a clear message?
For example, with current snapshot I get on Tru64 Unix:

nsNativeComponentLoader: autoregistering succeeded
###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file
xptiInterfaceInfoManager.cpp, line 1936
Break: at file xptiInterfaceInfoManager.cpp, line 1936


The problem is that xpti.dat is being opened in write mode. That fails as the
user doesn't have right to write the file. For what do we need wriet access to
the file? Why does mozilla continue execution(it runs then but without any
window, and strace tell me it's polling something)?

Comment 11

[Konstantin Svist]

Attachment: another example

also had this problem (could not start Tb), took a while to find it (had to move files one by one to see when Tb can start again)
hope this gets fixed soon

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Same happens to my while testing the current Firefox installer. I upgraded multiple times from 1.5.0.x to 2.0.0.3, installed 1.5.0.x and uninstalled it again. After a while I wasn't able to start Firefox 2.0.0.3 anymore. The crash report appears directly after I double clicked the Firefox icon. Talkback doesn't get fired.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: current version of a broken compreg.dat

Comment 15

[timeless]

in the first case, my guess is:
+{7ee2a4c0-4b93-17d3-ba18-0060b0f199a2},@mozilla.org/scriptsecuritymanager;1,,scriptsecuritymanager,rel:caps.dll

(not sure, i'd need to check some more files)

in the other two cases, i have no idea.

i think that it'd help me if people where to split their working and non working files by sections, sort them, and then diff the individual sections (and lastly merge the diffs)

Comment 16

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 17

[Benjamin Smedberg]

compreg.dat is no longer