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.
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?
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.
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.
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?
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
Comment on attachment 401793 [details] [diff] [review] try libcurl-gnutls.so.4 and set error_description Approved for 126.96.36.199, a=dveditz for release-drivers
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:188.8.131.52pre) Gecko/20091102 Shiretoko/3.5.5pre ID:20091102030746
Finally remembered to land this upstream: http://code.google.com/p/google-breakpad/source/detail?r=435