Crashreporter linked with libssl.so.4, libcrypto.so.4

VERIFIED FIXED

Status

()

Toolkit
Crash Reporting
--
major
VERIFIED FIXED
11 years ago
9 years ago

People

(Reporter: m., Assigned: ted)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
User-Agent:       Opera/9.20 (X11; Linux i686; U; en)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007070304 Minefield/3.0a7pre

Crashreporter program linked with libssl.so.4 and libcrypto.so.4, which do not exist in Debian.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Crashreporter does not work.

Expected Results:  
Should be linked with libssl.so, libcrypto.so.

ldd ./crashreporter
...
        libssl.so.4 => not found
        libcrypto.so.4 => not found
...
Component: General → Breakpad Integration
Product: Firefox → Toolkit
QA Contact: general → breakpad.integration

Comment 1

11 years ago
Gentoo doesn't have these either.

Simply symlinking them to lib{ssl,crypto}.so.0.9.8 makes breakpad work (AFAICT).
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

11 years ago
Hrm, I'm on openSUSE 10.2 and when crashing I get

/mnt/mozilla/packages/seamonkey-2.0a1pre.2007070808.en-US.linux-i686/seamonkey/crashreporter: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory

instead of the crashreporter - looks like that's happening on a broad range of distros :(
(Reporter)

Comment 3

11 years ago
(In reply to comment #1)
> Gentoo doesn't have these either.
> 
> Simply symlinking them to lib{ssl,crypto}.so.0.9.8 makes breakpad work
> (AFAICT).
> 

Even when symlinking them to proper libraries, it does not send the report, but the error message does not say why it fails.. but it's probably not related

Comment 4

11 years ago
Actually, sending did work fine for me when I did symlink the .so.4 versions to the .so.0.9.8 binaries.

Comment 5

11 years ago
Ted/Dave, who wants to take this? Linking directly against libssl.so makes me really nervous, but I'm not sure what the other options are.

Is this a problem where RedHat distros and other distros have radically different soversioning for these libs?
(Reporter)

Comment 6

11 years ago
Shouldn't applications link against static ssl/crypto libraries instead of shared libraries (for security)?
(Assignee)

Comment 7

11 years ago
We're just using `curl-config --libs`, which on my CentOS5 install gives:

-L/usr/kerberos/lib -lcurl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lidn -lssl -lcrypto -lz

I don't see libssl.so.4 in /usr/lib, I wonder if this is specific to our current CentOS4 build platform?  Anyone want to test the builds from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/linux-newref/latest-trunk/ ?  Those are built on the new linux refplatform, which uses CentOS 5.  If this isn't a problem there, then this bug is a non-issue, since we'll be switching to that machine for the official builds probably this week.

Comment 8

11 years ago
bsmedberg $ ldd linux-newref/firefox/crashreporter
...
        libssl.so.5 => /lib/libssl.so.5 (0x00cde000)
        libcrypto.so.5 => /lib/libcrypto.so.5 (0xf7ca4000)
(Assignee)

Comment 9

11 years ago
It seems to work ok if we just link with -lcurl instead of the entirety of CURL_LIBS.  I'll have a patch in a bit.
Assignee: nobody → ted.mielczarek
(Assignee)

Comment 10

11 years ago
Created attachment 271541 [details] [diff] [review]
Link with -lcurl instead of CURL_LIBS

This WFM, as libcurl pulls in those other libs anyway.
Attachment #271541 - Flags: review?(benjamin)

Comment 11

11 years ago
Comment on attachment 271541 [details] [diff] [review]
Link with -lcurl instead of CURL_LIBS

We should remove the MOZ_LIBCURL_LIBS configure check and do a AC_TRY_LINK using -lcurl.
Attachment #271541 - Flags: review?(benjamin) → review-

Comment 12

11 years ago
Running UBUNTU 7.04, normal is libssl.0.9.8
Firefox nightlies since about 7/06
Same error, except called lib is "libssl.so.6"

Somehow, we need the install to check for what is available -- or, of course, to link to a non-shared copy which we supply.
(Assignee)

Comment 13

11 years ago
The approach used in my patch (with the changes bsmedberg requested in comment 11) are the proper fix for this.
(Assignee)

Comment 14

11 years ago
Created attachment 272670 [details] [diff] [review]
AC_TRY_LINK -lcurl in configure

Ok, this adds an AC_TRY_LINK -lcurl (inside of an AC_CACHE_CHECK) to configure.in, and then links to -lcurl in the client Makefile (as before).
Attachment #271541 - Attachment is obsolete: true
Attachment #272670 - Flags: review?(benjamin)

Updated

11 years ago
Attachment #272670 - Flags: review?(benjamin) → review+
(Assignee)

Comment 15

11 years ago
Checked in.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 16

11 years ago
This doesn't seem to have fixed it.  I was pretty sure in my testing that it worked, I'm not sure if I missed something, or it never actually worked.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 17

11 years ago
Oh, I think I'm wrong.  I ran `ldd crashreporter` on the CentOS5 system I built it on, and it lists libssl.so.6 etc.  But if I copy it to a different system and run ldd on it, it lists the correct libssl.  Please comment if there are any further issues.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED

Comment 18

11 years ago
Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007071904 Minefield/3.0a7pre on Debian Etch and Sarge.

Comment 19

11 years ago
No, it's not fixed. Running ldd crashreporter I get

libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7429000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb72fd000)

but when I actually crash I get 

firefox/crashreporter: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 20

11 years ago
Works fine here now (Debian unstable).
I tested it by running crashreporter by hand and also by sending ABRT to firefox..
However the crash report is still not sent, for some unknown reason.

Comment 21

11 years ago
Oh, whoops. Apparently I was a day behind on updates and didn't notice. Works fine here, sorry.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED

Comment 22

11 years ago
verified fixed in 2007082304 3.0a8pre nightly build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.