Closed Bug 517493 Opened 12 years ago Closed 12 years ago

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

Categories

(Toolkit :: Crash Reporting, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta1-fixed
status1.9.1 --- .6-fixed

People

(Reporter: whimboo, Assigned: karlt)

Details

(Keywords: verified1.9.1, verified1.9.2)

Attachments

(1 file)

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.
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.
Yeah I agree.
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.
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)
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.
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
Closed: 12 years ago
Flags: wanted1.9.2?
Resolution: --- → FIXED
Version: 1.9.0 Branch → Trunk
Attachment #401793 - Flags: approval1.9.2?
Attachment #401793 - Flags: approval1.9.2? → approval1.9.2+
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
Attachment #401793 - Flags: approval1.9.1.5?
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+
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.
(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.
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
You need to log in before you can comment on or make changes to this bug.