Closed Bug 113141 Opened 23 years ago Closed 22 years ago

Browser not started with libjavaplugin_oji140.so link

Categories

(Core Graveyard :: Java: OJI, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: georg.colle, Assigned: joshua.xia)

Details

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112012

Mozilla 0.9.6 canot be started after placing symbolic link 
"libjavaplugin_oji.so" to 
/usr/java/.../j2re1.4.0/plugin/i386/ns610/libjavaplugin_oji140.so in
.../mozilla/plugins. The feedback agent is started instead.

Reproducible: Always
Steps to Reproduce:
1.create symbolic link to jdk1.4.0 beta3 oji
2.start mozilla-script
3.

Actual Results:  Mozilla browser not shown on the screen. Instead feedback agent
starts.

Expected Results:  start

Linux-Version: SuSE 7.3
j2sdk-Version: 1.4.0 Beta 3
Have you submitted any talkback reports?  If so, could you list the IDs here?

Also, are you spoofing your useragent by any chance?
The proper method for installing the 1.4 JRE on Linux is to link it to the
/components folder, or run regxpcom on it.
news://news.mozilla.org:119/3C03F1A7.9000105@graphics.cornell.edu
Please try to make symlink not to ./dist/bin/plugins
but to ./dist/bin/components.

Please close as dupe of 109033 if above helps.
Putting the link to jre 1.4.0 into mozilla/components has no effect. I just
re-installed jre 1.3.1 according to the installing instructions and am now
waiting for the final version of jre 1.4.0.
What do you mean "has no effect"? mozilla does not start?
java plugin is not found? 
Does removal of the link helps to get mozilla to start again?
Did you try to remove/rename ~/.mozilla ?

"No effect" means that the plugin is not recognized. And it remains unrecognized
after deleting ~/.mozilla.
Ok, so i assume mozilla with link to OJI lib from components starts normally
but applets do not work.

What does about:plugins page say?
Does it mention java plugin?

Is there any suspicious output when you start mozilla from command line?

It is true that mozilla starts normally with a link to OJI-lib placed in
components, but is that link processed at all? I have some doubts especially
because of the dialog box with the request to download an appropriate java
plugin the browser displays every time it has to start a java applet.

The about:plugins page shows only the default plugin
/usr/local/mozilla/plugins/libnullplugin.so. No java plugin is mentioned.

Starting mozilla from the command line does not produce any output.

Could the difficulties we are concerned with have to do with the fact that I
placed mozille in /usr/local instead of my home directory?
Does the browser need environment variables to find the jdk1.4.0ß3-Plugin in
mozilla/components, such as "SHLIB_PATH", "MOZILLA_DIR", "LD_LIBRARY_PATH",
"ADDON_PATH", or "LIBPATH"? If yes, we have found the error because KDE sets
them by default to /opt/mozilla or /opt/mozilla/components, respectively,
whereas mozilla is placed acually in /usr/local/mozilla.
Status: UNCONFIRMED → NEW
Ever confirmed: true
When I tried the method suggested, I get the following error:

[root@samba mozilla]# ./run-mozilla.sh ./regxpcom
/usr/local/java/jre/plugin/i386/ns610/libjavaplugin_oji140.so 
**************************************************
nsNativeComponentLoader:
SelfRegisterDll(/usr/local/java/jre/plugin/i386/ns610/libjavaplugin_oji140.so)
Load FAILED with error:
/usr/local/java/jre/plugin/i386/ns610/libjavaplugin_oji140.so: undefined symbol:
GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager
**************************************************
Registration successful for
/usr/local/java/jre/plugin/i386/ns610/libjavaplugin_oji140.so

When the browser starts up, it doesn't show anything related to java in
about:plugins 

I have compiled Mozilla with gcc-3.1 (CVS). The java plugin is from j2sdk 1.4.0
release candidate.

I also tried the symbolic link trick. What else should be done to fix this ?
Added myself to CC list.
kitty: I guess your problem is different and due to changed C++ mangling in 
         new gcc version (see bug 116444)

georg: Could you please try ./run-mozilla.sh ./regxpcom
/usr/local/mozilla/plugins/libjava*
    and 
       ./run-mozilla.sh /usr/bin/ldd /usr/local/mozilla/plugins/libjava* 
    post output here?
I'm not the origional reporter, but I have the same problem, minus the crash. 
Currently I'm on a CVS build from (12-apr-2002) with all the default options.

Mozilla does not crash on startup however, merely fails to correctly load the
plugin with the undefined symbol error message.

charles: Please try to make symlink from components/ instead of plugins/.
         What is you mozilla version? Did you built it youself?
          If so then what is your gcc version?
I, too am experiencing a similar problem using a nightly build from
a couple days ago on Solaris 8 w/JDK 1.4.0.

Environment:
 Solaris 8, SunOS kathadin 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-60
 Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9+) Gecko/20020417, build
2002041722
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)

[1] Following the suggestion to symlink libjavaplugin_oji140.so in 
the mozilla components dir, mozilla starts correctly but 
  a) visiting http://java.sun.com/ results in a prompt to download
     the plugin.
  b) choosing Help->About Plugins core dumps the browser with the 
     following backtrace (signal 9):
#0  0xff1af890 in nsNativeComponentLoader::SelfRegisterDll ()
   from /export/share/mozilla/libxpcom.so
(gdb) bt
#0  0xff1af890 in nsNativeComponentLoader::SelfRegisterDll ()
   from /export/share/mozilla/libxpcom.so
#1  0xff1b0acc in nsNativeComponentLoader::AutoRegisterComponent ()
   from /export/share/mozilla/libxpcom.so
#2  0xff1af4ac in nsNativeComponentLoader::RegisterComponentsInDir ()
   from /export/share/mozilla/libxpcom.so
#3  0xff1af36c in nsNativeComponentLoader::AutoRegisterComponents ()
   from /export/share/mozilla/libxpcom.so
#4  0xff1ad568 in nsComponentManagerImpl::AutoRegisterImpl ()
   from /export/share/mozilla/libxpcom.so
#5  0xff1addbc in nsComponentManagerImpl::AutoRegister ()
   from /export/share/mozilla/libxpcom.so
#6  0xfd35dd90 in nsPluginHostImpl::ReloadPlugins ()
   from /export/share/mozilla/components/libgkplugin.so
#7  0xfd94e5a0 in PluginArrayImpl::Refresh ()
   from /export/share/mozilla/components/libjsdom.so
#8  0xfd94e838 in PluginArrayImpl::Refresh ()
   from /export/share/mozilla/components/libjsdom.so
#9  0xff1cf774 in XPTC_InvokeByIndex () from /export/share/mozilla/libxpcom.so
#10 0xfe906594 in XPCWrappedNative::CallMethod ()
   from /export/share/mozilla/components/libxpconnect.so
#11 0xfe90c17c in XPC_WN_CallMethod ()
   from /export/share/mozilla/components/libxpconnect.so
#12 0xff2b6f80 in js_Invoke () from /export/share/mozilla/libmozjs.so
#13 0xff2bea80 in js_Interpret () from /export/share/mozilla/libmozjs.so
#14 0xff2b73e4 in js_Execute () from /export/share/mozilla/libmozjs.so
#15 0xff296314 in JS_EvaluateUCScriptForPrincipals ()
   from /export/share/mozilla/libmozjs.so
#16 0xfd92e5d0 in nsJSContext::EvaluateString ()
   from /export/share/mozilla/components/libjsdom.so
#17 0xfd78c7dc in nsScriptLoader::EvaluateScript ()
   from /export/share/mozilla/components/libgkcontent.so
#18 0xfd78c430 in nsScriptLoader::ProcessRequest ()
   from /export/share/mozilla/components/libgkcontent.so
#19 0xfd78c194 in nsScriptLoader::ProcessScriptElement ()
   from /export/share/mozilla/components/libgkcontent.so
#20 0xfd5f8544 in nsHTMLScriptElement::SetDocument ()
   from /export/share/mozilla/components/libgkcontent.so
---Type <return> to continue, or q <return> to quit---
#21 0xfd5c6dd8 in nsGenericHTMLContainerElement::AppendChildTo ()
   from /export/share/mozilla/components/libgkcontent.so
#22 0xfd61bf68 in HTMLContentSink::ProcessSCRIPTTag ()
   from /export/share/mozilla/components/libgkcontent.so
#23 0xfd616fd0 in HTMLContentSink::AddLeaf ()
   from /export/share/mozilla/components/libgkcontent.so
#24 0xfdb347bc in CNavDTD::AddLeaf ()
   from /export/share/mozilla/components/libhtmlpars.so
#25 0xfdb32484 in CNavDTD::HandleScriptToken ()
   from /export/share/mozilla/components/libhtmlpars.so
#26 0xfdb33da4 in CNavDTD::OpenContainer ()
   from /export/share/mozilla/components/libhtmlpars.so
#27 0xfdb30648 in CNavDTD::HandleDefaultStartToken ()
   from /export/share/mozilla/components/libhtmlpars.so
#28 0xfdb313e0 in CNavDTD::HandleStartToken ()
   from /export/share/mozilla/components/libhtmlpars.so
#29 0xfdb2f9f0 in CNavDTD::HandleToken ()
   from /export/share/mozilla/components/libhtmlpars.so
#30 0xfdb2ec04 in CNavDTD::BuildModel ()
   from /export/share/mozilla/components/libhtmlpars.so
#31 0xfdb43084 in nsParser::BuildModel ()
   from /export/share/mozilla/components/libhtmlpars.so
#32 0xfdb42d74 in nsParser::ResumeParse ()
   from /export/share/mozilla/components/libhtmlpars.so
#33 0xfdb44b1c in nsParser::OnDataAvailable ()
   from /export/share/mozilla/components/libhtmlpars.so
#34 0xfdacf04c in nsDocumentOpenInfo::OnDataAvailable ()
   from /export/share/mozilla/components/liburiloader.so
#35 0xfdf46040 in nsJARChannel::OnDataAvailable ()
   from /export/share/mozilla/components/libnecko.so
#36 0xfdeff004 in nsOnDataAvailableEvent::HandleEvent ()
   from /export/share/mozilla/components/libnecko.so
#37 0xfdeecfe4 in nsARequestObserverEvent::HandlePLEvent ()
   from /export/share/mozilla/components/libnecko.so
#38 0xff1b506c in PL_HandleEvent () from /export/share/mozilla/libxpcom.so
#39 0xff1b4f9c in PL_ProcessPendingEvents ()
   from /export/share/mozilla/libxpcom.so
#40 0xff1b6048 in nsEventQueueImpl::ProcessPendingEvents ()
---Type <return> to continue, or q <return> to quit---
   from /export/share/mozilla/libxpcom.so
#41 0xfde2fa88 in nsAppShell::SetDispatchListener ()
   from /export/share/mozilla/components/libwidget_gtk.so
#42 0xfde2f73c in keysym2ucs ()
   from /export/share/mozilla/components/libwidget_gtk.so
#43 0xfedf6020 in g_io_unix_dispatch (source_data=0xea280, 
    current_time=0xffbedf48, user_data=0x1b1810) at giounix.c:135
#44 0xfedf7cfc in g_main_dispatch (dispatch_time=0xffbedf48) at gmain.c:656
#45 0xfedf8598 in g_main_iterate (block=-18752180, dispatch=1) at gmain.c:877
#46 0xfedf87ac in g_main_run (loop=0x1c2b28) at gmain.c:935
#47 0xfef4a488 in gtk_main () at gtkmain.c:524
#48 0xfde30024 in nsAppShell::Run ()
   from /export/share/mozilla/components/libwidget_gtk.so
#49 0xfe84e968 in nsAppShellService::Run ()
   from /export/share/mozilla/components/libnsappshell.so
#50 0x19580 in getCountry ()
#51 0x19f4c in main ()

2) Removing all traces of libjavaplugin*.so from the mozilla directory
and attempting to use regxpcom to register this so /also/ results
in a core dump:

$ ( setenv MOZILLA_FIVE_HOME `pwd`; setenv LD_LIBRARY_PATH $MOZILLA_FIVE_HOME;
./regxpcom /opt/javadev/jdk1.4/jre/plugin/sparc/ns610/libjavaplugin_oji140.so )
Bus error (core dumped)

#0  0xff2af890 in nsNativeComponentLoader::SelfRegisterDll ()
   from /export/share/mozilla/libxpcom.so
#1  0xff2b0acc in nsNativeComponentLoader::AutoRegisterComponent ()
   from /export/share/mozilla/libxpcom.so
#2  0xff2adac4 in nsComponentManagerImpl::AutoRegisterComponent ()
   from /export/share/mozilla/libxpcom.so
#3  0xff2adda4 in nsComponentManagerImpl::AutoRegister ()
   from /export/share/mozilla/libxpcom.so
#4  0x10dd8 in Register ()
#5  0x11204 in ProcessArgs ()
#6  0x11330 in main ()

= ============

Is there a C++ compiler mismatch going on here?
dj dot hagberg at sun dot com
I've been getting this bug for a couple of months now with j2sdk1.4.  I was
hoping that it would go away, but it hasn't, most recently segfaulting Linux
nightly 2002052507.

I stick it in the following place:
ln -s $JAVA_HOME/jre/plugin/i386/ns610/libjavaplugin_oji140.so
mozilla/components/libjavaplugin_oji140.so

I've also tried it with the ns600 plugin.  The segfault is:
/usr/local/mozilla/mozilla/run-mozilla.sh: line 72: 16570 Segmentation fault   
  $prog ${1+"$@"}

I'm using Redhat Linux 7.3
I ran into this bug on Mozilla 1.1 running on Solaris 9 with J2SE1.4. The trick
of renaming ~/.mozilla/plugins to ~/.mozilla/components worked in that Mozilla
stopped crashing, but the Java plug-in itself did not register in the
about:plugins page.

I can add two more pieces of information:

* I tested that plugins are working in general by installing and testing the
Flash 5 plugin. It registers in the about:plugins page and viewing test pages
works fine. BTW, both ~/.mozilla/plugins and ~/.mozilla/components work for the
Flash 5 plugin.

* I tried different JRE versions (1.4 and 1.3.1) and different versions of the
libjavaplugin_oji.so shared library.
There were some history behind some problems of linking java plugin lib to
"components" directory and running regxpcom. The right way to link the java
plugin lib now is to link it to "plugins" directory. If you currently have a
link to "components", remove (or unlink it) first, then link
libjavaplugin_oji.so to "plugins". 
Just get a recent mozilla and JRE (download them from mozilla.org and
java.sun.com/j2se), then you can either go to a site using java (applet) and you
will be prompted to download JRE, or you can link JRE to "plugins" yourself.
Either way, the Java plugin should work.
Chris Petersen is a new QA contact for oji component. His email is:
petersen@netscape.com
Assignee: joe.chou → petersen
fixing small error for pmac@netscape.com (filter with : SPAMMAILSUCKS)
Assignee: petersen → joe.chou
QA Contact: pmac → petersen
reassign to me
Assignee: joe.chou → joshua.xia
Reporter: Can you try latest JRE as comment 20 said? Thanks
Closing because this works for me on Linux(RH8.0) mozilla1.2 JRE1.4.1_01
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Summary: Browser not started with livjavaplugin_oji140.so link → Browser not started with libjavaplugin_oji140.so link
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: