Bug 201778 - Eclipse misusing NS_InitEmbedding(): needs to use NS_InitXPCOM3()
Eclipse misusing NS_InitEmbedding(): needs to use NS_InitXPCOM3()
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
:
: 202145 202292 202332 205083 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-08 15:55 EDT by Andrew Overholt
Modified: 2007-11-30 17:11 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-05 15:57:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backtrace when attempting to view slashdot (5.75 KB, text/plain)
2006-09-25 15:33 EDT, Andrew Overholt
no flags Details
backtrace when attempting to view osnews (5.75 KB, text/plain)
2006-09-25 15:35 EDT, Andrew Overholt
no flags Details

  None (edit)
Description Andrew Overholt 2006-08-08 15:55:31 EDT
Description of problem:
/usr/bin/java: symbol lookup error: /usr/share/eclipse/configuration/org.eclipse
.osgi/bundles/77/1/.cp/libswt-mozilla-gtk-3232.so: undefined symbol:
NS_InitEmbedding

This is a blocker on Eclipse for FC6.

Version-Release number of selected component (if applicable):
firefox-1.5.0.5-8.i386

How reproducible:
Always

Steps to Reproduce:
1. Install eclipse-platform via yum
2. run eclipse
  
Additional info:
rawhide:  
for f in `rpm -ql firefox | grep .so$`; do nm -D $f | grep NS_InitEmbedding &&
echo $f; done
<no output>

rhel4:
for f in `rpm -ql mozilla | grep .so$`; do nm -D $f | grep NS_InitEmbedding &&
echo $f; done
00013ae4 T NS_InitEmbedding
/usr/lib/mozilla-1.7.13/libgtkembedmoz.so
Comment 1 Andrew Overholt 2006-08-10 22:48:45 EDT
*** Bug 202145 has been marked as a duplicate of this bug. ***
Comment 2 Ben Konrath 2006-08-12 09:31:22 EDT
*** Bug 202292 has been marked as a duplicate of this bug. ***
Comment 3 Ben Konrath 2006-08-12 19:18:34 EDT
*** Bug 202332 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Overholt 2006-08-30 14:10:51 EDT
Adding as blocker for test3 and final.
Comment 5 Ben Konrath 2006-09-04 14:11:30 EDT
*** Bug 205083 has been marked as a duplicate of this bug. ***
Comment 6 Christopher Aillon 2006-09-06 20:28:46 EDT
Trying to track down why this is no longer around, but in the meantime: do one
of the NS_InitXPCOM* methods do what you need? 
http://lxr.mozilla.org/mozilla/source/xpcom/build/nsXPCOM.h
Comment 7 Christopher Aillon 2006-09-06 22:27:03 EDT
Okay, more information.  NS_InitEmbedding was an internal API that was never
intended to be used by anything other than Mozilla itself.  The fact that it was
is an artifact from the old mozilla days.  Moving forward, you need to move code
away from that.  We have two options to fix this issue right for FC6:

1) Fix the Eclipse code to refer to NS_InitXPCOM3() and if Eclipse relies on the
auto component registration stuff that NS_InitEmbedding did, it should do that
itself with code such as:

  nsCOMPtr<nsIComponentRegistrar> registrar;
  nsresult rv = NS_GetComponentRegistrar(getter_AddRefs(registrar));
  if (NS_FAILURE(rv)) return rv;
  rv = registrar->AutoRegister(nsnull);

2) Add an extra step to the mozilla build process to add NS_InitEmbedding and
co. into a static library which Eclipse can link against.  This seems to be
possible by doing some make file hackery.


Option 1 makes the most sense long term and I think we should aim for that....
Comment 8 Christopher Aillon 2006-09-06 22:30:01 EDT
Moving over to eclipse and re-summarizing...
Comment 9 Andrew Overholt 2006-09-07 23:16:15 EDT
(In reply to comment #7)
> 1) Fix the Eclipse code to refer to NS_InitXPCOM3() and if Eclipse relies on the

Thanks for the information.  We have a patch that appears to work and we're
trying a full build now.  Hopefully this will make it into rawhide tomorrow or
the next day.
Comment 10 Ben Konrath 2006-09-08 02:01:20 EDT
Yeah, thanks for the info. 

Andrew, things seem to be working OK. There's a browser in Window -> Show View
-> Other -> Genereal and the only problem I found was that slashdot crashes
Eclispe.  Unfortunately no useful information is printed so we'll need to debug
that. I browsed around to some other sites and things seem to work besides the
slashdot thing so I ended up pushing a build (3.2.0-5).
Comment 11 Ben Konrath 2006-09-11 11:17:50 EDT
The fix just hit dist-fc6 but I'm keeping the bug open because of the problem
with slashdot mentioned above. Removing FC6Blocker and FC6Test3Blocker because
Eclipse now starts.
Comment 12 Christopher Aillon 2006-09-12 16:28:58 EDT
I'll note that NS_InitEmbedding used nsILocalFile, and NS_InitXPCOM3 uses
nsIFile which could be a reason for crashes since it looks like you aren't
changing what gets passed to it.
Comment 13 Andrew Overholt 2006-09-25 15:05:53 EDT
Mozilla reference page:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201778
Comment 14 Andrew Overholt 2006-09-25 15:33:49 EDT
Created attachment 137082 [details]
backtrace when attempting to view slashdot

I managed to attach to an SWT browser example using gdb and this is the stack
trace that I got.  It was when it was loading slashdot.org.  I got a similar
trace for osnews.com and I'll post that next.
Comment 15 Andrew Overholt 2006-09-25 15:35:48 EDT
Created attachment 137083 [details]
backtrace when attempting to view osnews
Comment 16 Javier Pedemonte 2006-09-25 17:06:11 EDT
No, you should be using NS_InitEmbedding.  When building libswt-mozilla-gtk, you
should link in the libembed_base_s.a; this provides the NS_InitEmbedding method.
 You can get that library from the SDK
(ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.13/gecko-sdk-i686-pc-linux-gnu-1.7.13.tar.gz).
 We had this working a while ago (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=61384).  What changed to cause
this issue?
Comment 17 Andrew Overholt 2006-10-05 15:57:45 EDT
This is fixed in our RPMs > 3.2.1-3.fc6.  I will track this upstream for 3.3.
Comment 18 Christopher Aillon 2006-10-05 18:22:03 EDT
(In reply to comment #16)
> No, you should be using NS_InitEmbedding.  When building libswt-mozilla-gtk, you
> should link in the libembed_base_s.a; this provides the NS_InitEmbedding method.

Javier, Mozilla 1.7.13 has many outstanding critical security issues.  

Additionally, static libraries are considered evil, especially in
security-ridden software such as Mozilla, which has a new security update nearly
every month, which fixes as many as 30 critical issues.  See
http://people.redhat.com/drepper/no_static_linking.html.  So, We don't and won't
ship libembed_base_s.a.

Additionally, NS_InitEmbedding was never intended to be for embeddors to be
used, and it was unfortunate that it was available for application embeddors in
the first place -- an accident according to Benjamin Smedberg.  Feel free to
talk to bsmedberg from the Mozilla Corporation for more details.
Comment 19 Andrew Overholt 2006-10-06 14:46:21 EDT
I've verified this fix on i386, x86_64, and ppc.  I will try other architectures
if I can get access to hardware.
Comment 20 Steve Milner 2006-10-06 14:50:08 EDT
Eclipse now seems to work on Intel Mac's.

Note You need to log in before you can comment on or make changes to this bug.