Bug 201778
| Summary: | Eclipse misusing NS_InitEmbedding(): needs to use NS_InitXPCOM3() | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew Overholt <overholt> | ||||||
| Component: | eclipse | Assignee: | Andrew Overholt <overholt> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | caillon, fedora, jhpedemonte, mauri.korkeala, mlists, pombredanne, smilner, wtogami | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-10-05 19:57:45 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Andrew Overholt
2006-08-08 19:55:31 UTC
*** Bug 202145 has been marked as a duplicate of this bug. *** *** Bug 202292 has been marked as a duplicate of this bug. *** *** Bug 202332 has been marked as a duplicate of this bug. *** Adding as blocker for test3 and final. *** Bug 205083 has been marked as a duplicate of this bug. *** 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 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.... Moving over to eclipse and re-summarizing... (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. 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). 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. 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. Mozilla reference page: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201778 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.
Created attachment 137083 [details]
backtrace when attempting to view osnews
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? This is fixed in our RPMs > 3.2.1-3.fc6. I will track this upstream for 3.3. (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. I've verified this fix on i386, x86_64, and ppc. I will try other architectures if I can get access to hardware. Eclipse now seems to work on Intel Mac's. |