M10 core dumps on startup

VERIFIED FIXED

Status

Core Graveyard
Viewer App
P3
critical
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: gsstark, Assigned: Suresh Duddi (gone))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
#0  0x400e2a86 in nsNativeComponentLoader::AutoRegisterComponent () from
/usr/local/lib/m10/package/libxpcom.so
We've outdone ourselves, M10 doesn't even get as far as opening an X window.
Is this some kind of library version skew? I'm on a basically straight potato
system

#1  0x400e241c in nsNativeComponentLoader::RegisterComponentsInDir () from
/usr/local/lib/m10/package/libxpcom.so
#2  0x400e22d5 in nsNativeComponentLoader::AutoRegisterComponents () from
/usr/local/lib/m10/package/libxpcom.so
#3  0x400e1203 in nsComponentManagerImpl::AutoRegister () from
/usr/local/lib/m10/package/libxpcom.so
#4  0x400e4cce in nsComponentManager::AutoRegister () from
/usr/local/lib/m10/package/libxpcom.so
#5  0x805bdd5 in nsViewerApp::AutoregisterComponents ()
#6  0x805bdf7 in nsViewerApp::SetupRegistry ()
#7  0x805bef8 in nsViewerApp::Initialize ()
#8  0x805ff5e in main ()
#9  0x4041978a in __libc_start_main () from /lib/libc.so.6
(Reporter)

Comment 1

19 years ago
Oops, sorry for putting the comment in the middle of the backtrace, @#$ web
forms :)

Updated

19 years ago
Assignee: rickg → dp

Comment 2

19 years ago
DP -- here's one for you, since the stack trace involves component manager.
Additional notes:
  1. It's in viewer so you may choose to ignore
  2. I was unable to reproduce this
(Assignee)

Comment 3

19 years ago
Do you have funny characters in the path where you installed M10. Also could you
give me a log from xpcom. Here is how you get it:

setenv NSPR_LOG_MODULES nsComponentManager:5
setenv NSPR_LOG_FILE xpcom.log

Run viewer/apprunner whichever you see the crash in. Add the file xpcom.log as
an attachment to the bug.
(Reporter)

Comment 4

19 years ago
Created attachment 2163 [details]
$ export NSPR_LOG_MODULES=nsComponentManager:5 NSPR_LOG_FILE=xpcom.log
(Reporter)

Comment 5

19 years ago
I don't think that worked:

$ export NSPR_LOG_MODULES=nsComponentManager:5 NSPR_LOG_FILE=xpcom.log
$ ./apprunner
Unrecognized NSPR_LOG_MODULE: nsComponentManager=5
Gtk-WARNING **: /usr/lib/libgdk_imlib.so.1: undefined symbol: gdk_display
...the above repeated several dozen times...
Segmentation fault
[Exit 139 (SIGSEGV)]
(Reporter)

Comment 6

19 years ago
the path is: /u3/downloads/m10/package

MOZILLA_FIVE_HOME=/u3/downloads/m10/package
  LD_LIBRARY_PATH=/u3/downloads/m10/package
      MOZ_PROGRAM=./viewer
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 7

19 years ago
Are you sure you deleted ~/.mozilla/registry

The format of that changed in M10. Could you try that.

Also delete bin/component.reg
(Reporter)

Comment 8

19 years ago
Two points:
1) MOZILLA_FIVE_HOME is the download directory, so shouldn't .mozilla/register
be created there?

and
2) It works fine if I build it myself, it's just the precompiled binary that
crashes. So it seems unlikely to be ~/.mozilla/registry.

But I'll try it anyways
(Reporter)

Comment 9

19 years ago
Isn't bugzilla supposed to be sending me mail with your comments?
That's why there's such a delay between my updates, I don't think to
check up on the web page frequently and don't seem to be getting e-mail.
(Reporter)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

19 years ago
Hm, well that does seem to have fixed it, ok, ship it!

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 11

19 years ago
marking Verified.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.