9497 - [PP]on startup, hangs: failure to load file://../navigator.xul on linux with necko enabled

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[justin hugh daly]

using july 8 checkout, configured --with-necko on linux 2.2.10, can always
reproduce the following crash:

616 daly
%mozilla-apprunner.sh
[~/src/mozilla/dist/bin]
MOZILLA_FIVE_HOME=/home/jdaly/src/mozilla/dist/bin
  LD_LIBRARY_PATH=/home/jdaly/src/mozilla/dist/bin:.
      MOZ_PROGRAM=./apprunner
        moz_debug=0
     moz_debugger=
nsComponentManager: Autoregistration begins. dir =
/home/jdaly/src/mozilla/dist/bin/components
**************************************************
nsComponentManager:
Load(/home/jdaly/src/mozilla/dist/bin/components/libjar50.so) FAILED with error:
/home/jdaly/src/mozilla/dist/bin/components/libjar50.so: undefined symbol:
inflate
**************************************************
**************************************************
nsComponentManager:
Load(/home/jdaly/src/mozilla/dist/bin/components/libxpinstall.so) FAILED with
error: /home/jdaly/src/mozilla/dist/bin/components/libxpinstall.so: undefined
symbol: crc32
**************************************************
nsComponentManager: Autoregistration ends. dir =
/home/jdaly/src/mozilla/dist/bin/components
Unable to enumerator app shell components, GetSubtree rv=0x80510003
ProfileName : justin
ProfileDir  : /home/jdaly/.mozilla/justin
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=16
Using '/home/jdaly/src/mozilla/dist/bin' as the resource: base
Got the event queue from the service
Calling gdk_input_add with event queue
nsDocumentBindInfo::OnStopRequest: Load of URL
'file:///home/jdaly/src/mozilla/dist/bin/res/samples/navigator.xul' failed.
Error code: 16389
Unable to enumerator app shell components, GetSubtree rv=0x80510003

Gtk-CRITICAL **: file gtkmain.c: line 533 (gtk_main_quit): assertion `main_loops
!= NULL' failed.


after which mozilla hangs.

when compiled w/o --enable-necko all is fine (even the inflate and crc32 errors)

Comment 1

[Gagan]

Andreas you know something about this?

Comment 2

[Andreas Otte]

Haven´t seen that load problems, but got sometimes some complaints when loading
libraptorhtml about frame stuff. Haven´t followed that yet.

The problem with loading navigator.xul was the known problem with the missing
chrome/js implementation. This error doesn´t happen anymore with the new builds.

Comment 3

[Andreas Otte]

Maybe this posting (netlib/build/beos newsgroups) from Duncan Wilcox can share
some general light on the link situation:




Hi,

I have started trying to build with Necko enabled under BeOS. BeOS requires
each shared library to be linked against every other shared library from
which it pulls symbols. I have developed a link-time dependency generator
that uses objdump to look for undefined symbols among the defined ones of
other libs (you can find it under mozilla/config/beos/depend.pl).

I have stepped into a problem with Necko in that the following symbols:

nsresult NS_NewURI(nsIURI* *result, const char* spec, nsIURI* baseURI)
nsresult NS_NewURI(nsIURI* *result, const nsString& spec, nsIURI* baseURI)

defined in mozilla/netwerk/util/src/nsNeckoUtil.cpp, are only exported by
libraptorhtml.so and librdf.so (both are components) but are imported
by the following libraries:

libjsdom.so
libnsappshell.so
libraptorgfx.so
libraptorhtmlpars.so
libraptorplugin.so
libraptorwebwidget.so
components/libender.so
components/libmozxfer.so
components/librelated.so
components/libstrres.so
components/libuconv.so
components/libxpinstall.so

I only discovered this because of a bug in my depend.pl that prevented
components/*.so libraries from being scanned for defined symbols.

This seems to be pretty bad since in theory the raptorhtml and rdf components
might not be loaded before jsdom, nsappshell, raptorgfx, raptorhtmlpars,
raptorplugin or raptorwebwidgets are used (as they are not components).

Maybe I don't understand enough of how Mozilla shared libraries depend on
each other, but certainly the wierd dependency above breaks the BeOS binary
because neither librdf.so nor libraptorhtml.so are in memory when NS_NewURI
is looked up, and the components dir is (correctly) not in the search
path for shared libraries.

Maybe this is somehow related to the "nsNeckoUtil.cpp exports" thread in
netscape.public.mozilla.netlib?

This is crossposted to netlib, beos and builds, please excuse me if this is too
wide.

Duncan

Comment 4

[leger]

Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Comment 5

[Paul MacQuiddy]

so this problem is fixed then? if so, please mark resolved. For now, taking off
blocker list

Comment 6

[Andreas Otte]

The component loading messages are a result of a missing or miscofigured zlib. A
configure should do the job. I talked to Justin and his problems are gone in the
current build.

Comment 7

[Paul MacQuiddy]

thanks, marking verified then

Comment 8

[leger]

Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.