Bug 651503 - Sync fails to work in Rawhide: 'couldn't open library'
Summary: Sync fails to work in Rawhide: 'couldn't open library'
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xulrunner
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-09 17:39 UTC by Adam Williamson
Modified: 2018-04-11 17:51 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-22 16:36:53 UTC
Type: ---


Attachments (Terms of Use)
WeaveCrypto.js file (58.44 KB, text/plain)
2010-11-09 19:32 UTC, Adam Williamson
no flags Details


Links
System ID Priority Status Summary Last Updated
Mozilla Foundation 583209 None None None Never

Description Adam Williamson 2010-11-09 17:39:52 UTC
I just updated from F14, where I was using packaged Firefox 3 with the Sync extension installed from upstream, to Rawhide, which has Firefox 4 with Sync built-in. Unfortunately, Sync has stopped working.

I tried removing the Sync plugin (which was still listed as installed) and re-configuring Sync, but it still fails. The configuration process works and it can connect to the Sync server, but actually syncing always fails immediately. I get the 'Error While Syncing' message in Firefox's status bar, and on the Error Console I have an error:

couldn't open library
file:///usr/lib64/xulrunner-2/components/WeaveCrypto.js
Line: 137

I've verified that file exists and is part of the xulrunner package. Permissions:

[root@adam adamw]# ls -lZ /usr/lib64/xulrunner-2/components/WeaveCrypto.js 
-rw-r--r--. root root system_u:object_r:lib_t:s0       /usr/lib64/xulrunner-2/components/WeaveCrypto.js

SELinux is currently in Permissive mode, and I don't see any obvious errors in /var/log/messages .

Line 137 of the file seems to be trying to open libnss. There's what looks like a useful logging reference above, but I don't know where Sync logs to.

Comment 1 Adam Williamson 2010-11-09 17:41:53 UTC
ah. found it. about:sync-log URI. Neat.

That gives:

2010-11-09 09:32:00	Service.Main         DEBUG	Crypto check failed: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: resource://services-sync/util.js :: anonymous :: line 365"  data: no]
2010-11-09 09:32:00	Service.Main         INFO	Could not load the Weave crypto component. Disabling Weave, since it will not work correctly.
2010-11-09 09:32:00	Service.Main         INFO	Weave Sync disabled




-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Adam Williamson 2010-11-09 19:31:48 UTC
tried a quick-n-dirty 'ln -s /usr/lib64/libnss3.so /usr/lib' and that didn't help, FWIW.

attaching the .js file as requested by mcepl.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Adam Williamson 2010-11-09 19:32:32 UTC
Created attachment 459221 [details]
WeaveCrypto.js file

Comment 4 Matěj Cepl 2010-11-09 21:03:49 UTC
The code in question is this:

        // Open the NSS library.
        let nssfile = Services.dirsvc.get("GreD", Ci.nsILocalFile);
        let os = Services.appinfo.OS;
        switch (os) {
          case "WINNT":
          case "WINMO":
          case "WINCE":
            nssfile.append("nss3.dll");
            break;
          case "Darwin":
            nssfile.append("libnss3.dylib");
            break;
          case "Linux":
          case "SunOS":
          case "WebOS": // Palm Pre
            nssfile.append("libnss3.so");
            break;
          case "Android":
            // Android uses a $GREDIR/lib/ subdir.
            nssfile.append("lib");
            nssfile.append("libnss3.so");
            break;
          default:
            throw Components.Exception("unsupported platform: " + os, Cr.NS_ERROR_UNEXPECTED);
        }
        this.log("Using NSS library " + nssfile.path);

        // XXX really want to be able to pass specific dlopen flags here.
        let nsslib = ctypes.open(nssfile.path);

Seems to me like it is looking for libnss3.so in the XULRunner's directory, but not for the system library we link XULRunner against.

Comment 5 Matěj Cepl 2010-11-09 21:06:41 UTC
And of course, this bug is triaged as I can fully reproduce it even on i686 system.

Comment 6 Adam Williamson 2010-11-09 21:11:20 UTC
as a random side note, I've run upstream Firefox 4 beta tarballs on F14 and not seen this (sync works if you run an upstream Beta tarball on top of Fedora, in all my attempts). lots of variables there, though.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 7 Matěj Cepl 2010-11-09 23:17:24 UTC
(In reply to comment #6)
> as a random side note, I've run upstream Firefox 4 beta tarballs on F14 and not
> seen this (sync works if you run an upstream Beta tarball on top of Fedora, in
> all my attempts). lots of variables there, though.

That would agree with my theory in the comment 4 ... upstream Firefox obviously finds libnss3.so in the Firefox directory.

Comment 8 Adam Williamson 2010-11-10 06:37:42 UTC
I think this may be:

https://bugzilla.mozilla.org/show_bug.cgi?id=583209



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 9 Adam Williamson 2010-11-10 06:51:23 UTC
Yep, applying the patch from upstream for that bug fixes the problem. Then you hit a *different* problem - http://groups.google.com/group/mozilla-labs-weave/browse_thread/thread/3371cdef2ff5fb55?tvc=2&fwc=1 - which will be fixed when we push beta 7.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Adam Williamson 2010-11-10 06:51:35 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 11 Matěj Cepl 2010-11-10 07:27:35 UTC
(In reply to comment #9)
> Yep, applying the patch from upstream for that bug fixes the problem. Then you
> hit a *different* problem -
> http://groups.google.com/group/mozilla-labs-weave/browse_thread/thread/3371cdef2ff5fb55?tvc=2&fwc=1
> - which will be fixed when we push beta 7.

If I understand that http://snarkfest.net/blog/2010/09/28/using-sync-on-the-bleeding-edge/ correctly you may be saved even in the current situation by uninstalling addon and removing manually Sync store (no idea where it is; don't forget to backup your profile) and resyncing from the server your data to built-in old Sync.

Otherwise, yes, releasing addon incompatible with the main Firefox ... oh well :(

Comment 12 Matěj Cepl 2010-11-10 07:29:41 UTC
Concerning FF4b7 the only thing I see is https://wiki.mozilla.org/Releases

Firefox 4.0 Beta 7 | 2nd Half of September (tentative - behind schedule)

:(

https://wiki.mozilla.org/Releases/Firefox_4.0b7 has a bit more details, but nothing more certain.

Comment 13 Adam Williamson 2010-11-10 16:53:12 UTC
I saw a news story yesterday saying it was coming out today. We'll see.

I went with the easy fix the to FF4b6's-sync-is-too-old problem - just install the Sync plugin v1.5. It works fine that way. You would think they'd fight or something, but apparently not. I can't just revert to the older Sync, because my other systems run F14 with its packaged FF3, so no in-built Sync, so they have to use the plugin - and it's hard to run Firefox with an out of date plugin. It reeaaalllly wants them to be up to date. :)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 14 Adam Williamson 2010-11-10 16:54:11 UTC
it'd be trivial to patch this until the beta comes out, btw, but since you still need to manually work around the 'sync-is-too-old' bug and the beta's supposed to come soon, it may not be worth it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 15 Adam Williamson 2010-11-11 00:58:04 UTC
ff4b7 came out today, I believe that both issues would be solved with an update to that.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 16 Martin Stransky 2010-11-12 06:29:26 UTC
Beta 7 should be in rawhide now.

Comment 17 Adam Williamson 2010-11-12 06:45:55 UTC
nope, the xulrunner and firefox builds both failed :)

I emailed you fixes for xulrunner build (just need to drop a patch and rediff another, IIRC). firefox needs a trivial rediff to one patch, not sure beyond that.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 18 Adam Williamson 2010-11-12 06:46:23 UTC
actually, i didn't send the fix to you, but to dan and jan. I can forward to you if you like.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 19 Adam Williamson 2010-11-12 23:30:27 UTC
jon, I see you CCed yourself - if you want to fix this for yourself while we wait for the ff4b7 build to go through (I'd have fixed it up but I don't have access to firefox build), then all you need to do is patch the installed file manually with the changes from https://bugzilla.mozilla.org/show_bug.cgi?id=583209 , and then install the Sync 1.5.1 plugin, and it'll start working.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 20 Michael Cronenworth 2010-11-30 20:56:29 UTC
Adam, did the new build and patch work for you? I'm using Tom's Firefox 4 build for F14 that includes the fixes, but Sync still fails for me (same error as you). Tried SELinux in permissive mode, too.

Comment 21 Michael Cronenworth 2010-11-30 21:04:03 UTC
(In reply to comment #20)
> Adam, did the new build and patch work for you? I'm using Tom's Firefox 4 build
> for F14 that includes the fixes, but Sync still fails for me (same error as
> you). Tried SELinux in permissive mode, too.

Making a symbolic link in /usr/lib64/xulrunner-2.0b7 to /usr/lib64/libnss3.so fixes it. I'll note this to Tom.

Comment 22 Adam Williamson 2010-11-30 21:07:46 UTC
yes, it works fine for me. didn't have to add any symbolic links. if you added the extension to make it work in b6, you have to remove the extension for b7 to be happy, though.

Comment 23 Michael Cronenworth 2010-11-30 21:28:15 UTC
I still had the extension installed... shame on me. Symbolic link no longer required.

Comment 24 Martin Stransky 2010-12-22 16:36:53 UTC
Okay, closing.


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