Sending crash reports on Linux fail because libcurl is not installed by default

VERIFIED FIXED in mozilla1.9.3a1

Status

()

Toolkit
Crash Reporting
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: whimboo, Assigned: karlt)

Tracking

({verified1.9.1, verified1.9.2})

Trunk
mozilla1.9.3a1
x86
Linux
verified1.9.1, verified1.9.2
Points:
---

Firefox Tracking Flags

(status1.9.2 beta1-fixed, status1.9.1 .6-fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
When you are using an official build of Firefox and not the default one from the Ubuntu repository you will not be able to send any crash report. Sending the report relies on libcurl but this library is not installed by default on Ubuntu 9.04.

We should find another library which is installed by default or at least give a reasonable error message. This could happen in the log file or also in the crash reporter UI itself. The latter one would be more obvious to recognize and to fix.

Ted pointed me to this location where we use the library:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/linux/http_upload.cc#78
FWIW, I don't really think fixing this is worthwhile. I think getting bug 447771 fixed is really what will help.
(Reporter)

Comment 2

8 years ago
But that will not help us who have to run our nightly builds to verify fixes or finding regression ranges and do crash analysis. It's only a one time situation after a system installation but how should testers be aware of it? There is no sign anywhere which will let them know that libcurl has to be installed first.
That may be, but I don't think there's any other library that's going to be installed on all users' machines. I think the best we can hope for is to give a better error message.
(Reporter)

Comment 4

8 years ago
Yeah I agree.
(Assignee)

Comment 5

8 years ago
Does Ubuntu install libcurl-gnutls.so.4 by default?

We should probably try opening that if libcurl.so.4 fails.

If installed, a simple test would be to create a soft link called libcurl.so.4 in /usr/lib/ (nsExceptionHandler clobbers LD_LIBRARY_PATH) pointing to /usr/lib/libcurl-gnutls.so.4.
(Assignee)

Comment 6

8 years ago
Created attachment 401793 [details] [diff] [review]
try libcurl-gnutls.so.4 and set error_description

Debian gives the library a different name when it is built to use gnutls
instead of openssl, for licensing reasons.  Looks like most packages are being
moved to depend on the gnutls version.  Here's one example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519070#20

I'd expect /usr/lib/libcurl-gnutls.so.4 to be present due to this dependency
chain (at least):
update-manager-core -> python-gnupginterface -> gnupg -> libcurl3-gnutls

This patch also sets error_description so that the message in submit.log
changes from: 
  "Crash report submission failed:"
to:
  "Crash report submission failed: libcurl.so: cannot open shared object
   file: No such file or directory"

(The user still sees only "There was a problem submitting your report.")

Can we apply this patch directly in our tree?
Assignee: nobody → mozbugz
Status: NEW → ASSIGNED
Attachment #401793 - Flags: review?(ted.mielczarek)
(Assignee)

Comment 7

8 years ago
http://code.google.com/p/google-breakpad/issues/detail?id=336
I don't like taking local patches, since it makes it difficult to sort out what fixes we've taken from upstream. However, currently syncing to upstream requires some work, since the Linux client-side bits have been rewritten. I have bug 514188 filed on syncing up with upstream again. That being said, If we can land a fix upstream, it seems ok to take it locally as well, since we'll keep the fix when we sync up anyway.
(In reply to comment #6)
> This patch also sets error_description so that the message in submit.log
> changes from: 
>   "Crash report submission failed:"
> to:
>   "Crash report submission failed: libcurl.so: cannot open shared object
>    file: No such file or directory"
> 
> (The user still sees only "There was a problem submitting your report.")

I'm not sure if that's the greatest error message to present, but it's better than the nothing we have now.
Attachment #401793 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 401793 [details] [diff] [review]
try libcurl-gnutls.so.4 and set error_description

This is fine. I'll try to remember to check it in upstream as well.
(Assignee)

Comment 11

8 years ago
http://hg.mozilla.org/mozilla-central/rev/3fd26ee5928f

We should get this on 1.9.2 for Debian/Ubuntu users.
I'll request approval in a day or so.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: wanted1.9.2?
Resolution: --- → FIXED
Version: 1.9.0 Branch → Trunk
(Assignee)

Updated

8 years ago
Attachment #401793 - Flags: approval1.9.2?

Updated

8 years ago
Attachment #401793 - Flags: approval1.9.2? → approval1.9.2+
(Reporter)

Comment 12

8 years ago
Verified fixed on trunk with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090930 Minefield/3.7a1pre ID:20090930031238

Shall we also consider it for 1.9.1?
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.3a1
(Assignee)

Comment 13

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a4fecf8f6dbd
status1.9.2: --- → beta1-fixed
Flags: wanted1.9.2?
(Assignee)

Updated

8 years ago
Attachment #401793 - Flags: approval1.9.1.5?
(Reporter)

Comment 14

8 years ago
Verified fixed on 1.9.2 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20091004 Namoroka/3.6b1pre ID:20091004033810
Keywords: verified1.9.2
Comment on attachment 401793 [details] [diff] [review]
try libcurl-gnutls.so.4 and set error_description

Approved for 1.9.1.5, a=dveditz for release-drivers
Attachment #401793 - Flags: approval1.9.1.5? → approval1.9.1.5+
(Assignee)

Comment 16

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/592d82bb8df8
status1.9.1: --- → .5-fixed
(Reporter)

Comment 17

8 years ago
Samuel, do we want this for the 3.5.5 release? It's not on your list of bugs which we will take for 3.5.5 but would be really helpful to get people sending their reports.
No. We're only taking major stability fixes and we don't want to grow the release more than it needs to be.
(Reporter)

Comment 19

8 years ago
(In reply to comment #18)
> No. We're only taking major stability fixes and we don't want to grow the
> release more than it needs to be.

So the flag has to be updated to .6fixed once it is available.
Yes. We know. Drivers will handle moving flags.
(Reporter)

Comment 21

8 years ago
Verified fixed on 1.9.1 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5pre) Gecko/20091102 Shiretoko/3.5.5pre ID:20091102030746
Keywords: verified1.9.1
Finally remembered to land this upstream:
http://code.google.com/p/google-breakpad/source/detail?r=435
You need to log in before you can comment on or make changes to this bug.