181263 - crash on startup

Status: VERIFIED WORKSFORME

(Core :: XPConnect, defect)

Description

[Robert]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.01; Windows 98; NETWAY)
Build Identifier: self built nightly/experimental/gtk2/20021118

./configure --enable-default-toolkit=gtk2 --disable-gtktest --disable-mailnews -
-disable-ldap --disable-freetypetest --disable-freetype2 --enable-xft --disable-
postscript --disable-xprint --enable-crypto --disable-jsd --disable-installer --
disable-tests --enable-optimize='-O2 -pipe' --disable-dtd-debug --disable-
pedantic --disable-glibtest --with-system-jpeg --with-system-mng --with-system-
png --with-system-zlib --with-pthreads --with-default-mozilla-five-
home=/opt/gnome2/lib/mozilla --without-system-nspr 

built against gtk+-2.1.2

Reproducible: Always

Steps to Reproduce:
1. fetch source
2. build
3. start

Actual Results:  
mozilla crashes

Expected Results:  
starting up smoothly

I'm filing this bug after it was suggested by timless on irc.mozilla.org

Comment 1

[Robert]

Attachment: stack backtrace of crash

Comment 2

[David Bradley]

It looks like your interface information is trashed, or something is seriously
wrong with some of your files. It was in the process of throwing an exception
and then tried to invoke a getter on on the exception object, but instead got a
function.

Try erasing xpti.dat compreg.dat if you haven't already.

Comment 3

[Robert]

Attachment: dump of mozilla startup messages

Comment 4

[Robert]

I don't seem to have a compreg.dat (related to that mozilla installation) on my
disk and removing xpti.dat doesn't seem to make a difference. The new attachment
"dump of mozilla startup messages" shows an error message related to that.

Comment 5

[Andrew Schultz]

compreg.dat is in the components directory.

Comment 6

[Andrew Schultz]

Macintosh + Linux = OS X?

Comment 7

[Robert]

> compreg.dat is in the components directory.
No doubt it should be.

> Macintosh + Linux = OS X?
I'm running Yellow Dog Linux 2.3

Comment 8

[Robert]

1.2 doesn't seem to have the same problem.

Comment 9

[Robert]

Finally I figured it out. I must admit that it's all my fault. 

The problem occurs when I was building mozilla in the GARNOME
(http://gnome.org/~jdub/garnome/) environment which explicitely specifies a lot
of dirpaths like --bindir, --execdir, --libexecdir ...

I was adding --enable-default-mozilla-five-home=[prefix]/lib/mozilla because I'm
used to do so although I can't give any reason for that ;-)
This is a combination which seems to be illegal.

Sorry for the noise, 
Robert

Comment 10

[Phil Schwartau]

Robert: thanks for figuring this out! Based on your findings,
I'm going to resolve this as WORKSFORME, then -

Comment 11

[Phil Schwartau]

Marking Verified -